Preempting or resolving fraud disputes relating to billing aliases

ABSTRACT

In a computer-implemented method of pre-empting fraud disputes caused by billing aliases or unrecognized merchant billing names, an indication that a credit card financial transaction is unrecognizable by the card owner may be received. A billing alias for a merchant associated with the unrecognizable transaction may be determined, where the billing alias is named on a credit card statement as billing merchant. A brick and mortar name that the merchant associated with the billing alias is doing business as may be determined, and an electronic notification indicating the brick and mortar name of the merchant may be generated. The electronic notification may be transmitted to a mobile device of the card owner over a wireless communication channel for card owner review or approval to facilitate preventing financial disputes caused by unrecognized or unfamiliar billing aliases on credit card or other financial statements.

CROSS-REFERENCE TO RELATED APPLICATIONS

This claims the benefit of U.S. Patent Application No. 62/313,196, filedon Mar. 25, 2016 and entitled “Reducing Financial Fraud Using MachineLearning and Other Techniques,” U.S. Patent Application No. 62/318,423,filed on Apr. 5, 2016 and entitled “Reducing Financial Fraud UsingMachine Learning and Other Techniques,” U.S. Patent Application No.62/331,530, filed on May 4, 2016 and entitled “Reducing Financial FraudUsing Machine Learning and Other Techniques,” and U.S. PatentApplication No. 62/365,699, filed on Jul. 22, 2016 and entitled“Detecting and/or Preventing Financial Fraud Using Geolocation Data,”the disclosures of which are hereby incorporated herein by reference intheir entireties.

FIELD OF THE DISCLOSURE

The present disclosure generally relates to financial fraud and, morespecifically, to processing techniques that use machine learning tofacilitate the resolution or prevention of fraud-related disputes.

BACKGROUND

Financial fraud, in its many forms, is a problem of enormous magnitudeand scope, causing billions of dollars in economic losses and impactingmany millions of people. Types of financial fraud include use of a lostor stolen card, account takeover, skimming, chargeback (“friendly”)fraud, counterfeiting, forgeries and application (e.g., loanapplication) fraud, to name just a few. The problem only continues togrow as various technological advances, intended to improve convenienceand efficiency in the marketplace, provide new opportunities for badactors. For example, an ever-increasing amount of fraud may be linked toonline transactions made via the Internet.

Various software applications have been developed to detect potentiallyfraudulent transactions. For example, dollar amounts and geographiclocations have generally been used to flag particular credit or debitcard transactions, with cardholders then being contacted by employees ofthe card issuer to determine whether the transactions were indeedfraudulent. To ensure that most instances of fraud are captured,however, such techniques generally have a low threshold for triggering afraud alert. As a result, numerous fraud alerts are false positives. Theprevalence of false positives leads to a large cost in terms of thedrain on human resources (e.g., calling customers to discuss eachsuspect transaction, and/or other manual investigation techniques), andconsiderable distraction or annoyance for cardholders. To provide asolution to these shortcomings in the field of automated frauddetection, innovative processing techniques capable of reducing falsepositives are needed.

Other conventional processes relating to financial fraud are likewiseresource-intensive. For example, fraud dispute resolution (e.g., after acardholder has reported a fraudulent or unrecognized transaction)typically may involve a back-and-forth communication with an employee ofthe card issuer to try to ascertain whether a transaction was valid.This process may be time-consuming for both the cardholder and theemployee, and might fail to identify whether a charge was fraudulent.

BRIEF SUMMARY

The present embodiments may, inter alia, use new processing techniquesto facilitate the dispute resolution process (e.g., after a cardholderhas reported a fraudulent or unrecognized transaction), and/or toprevent disputes that may arise due to various factors (e.g., customerconfusion regarding billing aliases and/or expiration of introductoryoffers).

In one embodiment, a computer-implemented method of pre-empting frauddisputes caused by billing aliases or unrecognized merchant billingnames may include: (1) receiving, by one or more processors, anindication that a credit card financial transaction is unrecognizable bythe card owner; (2) determining, by the one or more processors, abilling alias for a merchant associated with the unrecognizable creditcard financial transaction, the billing alias being named on a creditcard statement as billing merchant; (3) determining, by the one or moreprocessors, a brick and mortar name that the merchant associated withthe billing alias is doing business as; (4) generating, by the one ormore processors, an electronic notification indicating the brick andmortar name of the merchant associated with the credit card financialtransaction; and/or (5) transmitting, by the one or more processors, theelectronic notification indicating the brick and mortar name of themerchant to a mobile device of the card owner over a wirelesscommunication channel for card owner review or approval to facilitatepreventing financial disputes caused by unrecognized or unfamiliarbilling aliases on credit card or other financial statements. The methodmay include additional, less, or alternate actions, including thosediscussed elsewhere herein.

In another embodiment, a computer system configured to pre-empt frauddisputes includes one or more processors configured to: (1) receive anindication that a credit card financial transaction is unrecognizable bythe card owner; (2) determine a billing alias for a merchant associatedwith the unrecognizable credit card financial transaction, the billingalias being named on a credit card statement as billing merchant; (3)determine a brick and mortar name that the merchant associated with thebilling alias is doing business as; (4) generate an electronicnotification indicating the brick and mortar name that the merchantassociated with the billing alias is doing business as; and/or (5)transmit the electronic notification indicating the brick and mortarname of the merchant to a mobile device of the card owner over awireless communication channel for card owner review or approval tofacilitate preventing financial disputes caused by unrecognized orunfamiliar billing aliases on credit card or other financial statements.The computer system may include additional, less, or alternatefunctionality, including that discussed elsewhere herein.

In another embodiment, a non-transitory, computer-readable medium storesinstructions that, when executed by one or more processors, cause theone or more processors to: (1) receive an indication that a credit cardfinancial transaction is unrecognizable by the card owner; (2) determinea billing alias for a merchant associated with the unrecognizable creditcard financial transaction, the billing alias being named on a creditcard statement as billing merchant; (3) determine a brick and mortarname that the merchant associated with the billing alias is doingbusiness as; (4) generate an electronic notification indicating thebrick and mortar name that the merchant associated with the billingalias is doing business as; and/or (5) transmit the electronicnotification indicating the brick and mortar name of the merchant to amobile device of the card owner over a wireless communication channelfor card owner review or approval to facilitate preventing financialdisputes caused by unrecognized or unfamiliar billing aliases on creditcard or other financial statements.

BRIEF DESCRIPTION OF THE DRAWINGS

The Figures described below depict various aspects of the systems andmethods disclosed herein. It should be understood that each Figuredepicts an embodiment of a particular aspect of the disclosed systemsand methods, and that each of the Figures is intended to accord with apossible embodiment thereof.

FIG. 1 depicts an exemplary environment in which techniques for frauddetection, verification and/or classification may be implemented,according to one embodiment.

FIG. 2 depicts an exemplary process flow for machine learning of frauddetection, verification and/or classification rules, according to oneembodiment.

FIGS. 3A-3F depict exemplary process flows for machine learning ofparticular types of fraud detection, verification and/or classificationrules, according to different embodiments.

FIGS. 4A-4F depict exemplary factors and algorithms that may be used inconnection with various fraud detection, verification and/orclassification rule sets, according to different embodiments.

FIG. 5 depicts a flow diagram of an exemplary method for facilitating afraud dispute resolution process involving a customer associated with afinancial account, according to one embodiment.

FIG. 6 illustrates an exemplary computer-implemented method of resolvingpotential disputes caused by customer confusion originating fromunrecognizable billing aliases on credit card or other billingstatements.

FIG. 7 illustrates an exemplary computer-implemented method ofpre-emptively resolving potential customer complaints caused byincreased charges for goods or services that are incurred after a lowprice, introductory offer expires.

FIG. 8 depicts an exemplary computer system in which the techniquesdescribed herein may be implemented, according to one embodiment.

DETAILED DESCRIPTION I. Exemplary Fraud Detection and/or Classification

The embodiments described herein relate to, inter alia, wholly orpartially automated detection, verification and/or classification offinancial fraud. For ease of explanation, and unless otherwise clearlyindicated by the context of usage, “detecting” or “determining” fraudmay be used herein to refer to initially flagging fraudulent (orpotentially fraudulent) activity, to verifying/confirming thatsuspect/flagged activity was indeed fraudulent, or generally to both.The systems and techniques described herein may be used, for example, toidentify, prevent and/or quantify/measure instances of lost or stolencard use, account takeover, counterfeiting, skimming, chargeback(“friendly”) fraud, collusive merchant fraud, application (e.g., loanapplication) fraud, mortgage fraud, and/or one or more other types offraud relating to existing and/or potential financial transactionsand/or accounts. Moreover, those skilled in the art will appreciate thatat least some of the technical advancements described below (and/orshown in the accompanying figures) are not necessarily restricted to thefinancial field.

In some embodiments, a fraud detection and/or classification system mayanalyze data relating to a number of existing or potential financialaccounts. The analysis/processing may be performed in batch processingoperations, or substantially in real-time (e.g., as the data isgenerated and/or as financial transactions occur, etc.), and the datamay be obtained from a variety of sources based upon the particularembodiment and/or scenario. In one embodiment, for example, data fromfinancial account records may be analyzed, along with data indicatingonline activity of an account holder, location data (e.g., globalpositioning satellite (GPS) data from a smartphone or vehicle of theaccount holder) and/or other data, to determine whether a particularfinancial transaction was fraudulent or likely fraudulent. The analysismay be performed automatically after the transaction has been made, ormay be performed in response to a person or algorithm flagging thetransaction as a potentially fraudulent one, for example.

The analysis may include determining whether the account holder hasexpressed interest in the object (e.g., product or service) of thetransaction or the merchant, and/or determining whether the transactionis consistent with spending patterns associated with the account holder(e.g., spending patterns identified using the account holder'stransaction records), for example. In the case of multiple accountholders (e.g. multiple credit or debit card holders), accuracy may beimproved by identifying spending patterns at the individual level ratherthan, or in addition to, at the aggregate account level. For example, amaximum amount of money typically spent in a single transaction (e.g.,over the course of a one-month window, etc.) may be determined for eachof two cardholders listed on a single account, and the maximum amountfor the cardholder who purportedly made a particular purchase may becompared to the purchase amount to determine whether fraud is suspected.

In another exemplary embodiment, financial transaction data may beanalyzed to determine whether a chargeback payment from the merchant oracquiring bank to a card issuer may be appropriate in connection with aparticular fraudulent transaction. For example, the card informationentry mode (e.g., collecting card information by inserting the card in achip reader, swiping the card, manually entering the card information,etc.), the transaction amount, the similarity to other transaction(s),and/or other information may be used to identify which fraudulenttransactions are relatively strong chargeback candidates. The analysismay be performed in response to a cardholder reporting the transactionas fraudulent, or after a card issuer has confirmed that the transactionwas fraudulent, for example. For the subset of instances where afraudulent transaction has been identified as a chargeback candidate, afull set of chargeback rules (e.g., devised by a card network entitysuch as VISA®, Mastercard®, American Express®, Discover®, etc.) may bemanually or automatically applied to determine whether a chargebackprocess should be initiated (or continued).

In another exemplary embodiment, application data (e.g., informationentered in fields of an online application) may be analyzed inconjunction with search terms entered by a user at a computing device(e.g., the device from which the user submitted the applicationinformation) to determine whether the person proffering the applicationis not the person that he or she purports to be. For example, if theperson submitting an application had previously used an Internet-basedsearch engine to search for results associated with the purportedapplicant's name (e.g., by using the name as a search term, possibly inaddition to other terms such as “address” and/or “employer,” etc.), theapplication may be flagged for suspected fraud, and subjected toadditional steps of manual and/or automated review.

In another exemplary embodiment, a fraud dispute resolution process(e.g., after a customer has reported a fraudulent or unrecognizedtransaction associated with his or her account) may be facilitated usingmachine learning techniques. For example, a machine learning program maybe trained, using past dispute resolution interactions with customersand the associated outcomes (fraud determinations), to identify varioustypes of information that, if elicited from customers, tend to beindicative of fraud or the absence thereof. When fraud is suspected fora particular transaction, one or more queries for the individualpurportedly making the transaction may be automatically generated usingthe types of information identified by the machine learning program, aswell as information about the suspect transaction and/or relatedtransactions (e.g., dates, locations, amounts, etc.). In someembodiments and/or scenarios, responses to the queries may be collectedand analyzed to automatically generate additional queries, with the endgoal of discerning whether the transaction was authorized. For example,queries may include asking whether a cardholder recalls particular othertransactions that appear on the cardholder's account and were madearound the same time as the suspect transaction (and/or from the samemerchant), asking whether the cardholder recalls being in a particularlocation at a particular time (e.g., a location associated with anothertransaction appearing on the cardholder's account), whether thecardholder is aware of a particular billing alias used by a merchant,and so on.

In another exemplary embodiment, image data corresponding to aparticular physical document (e.g., a personal or cashier's check, adriver's license or other identification card, etc.) may be analyzed,using rules generated by a machine learning program, to determinewhether the document is, or may be, fraudulent (e.g., a counterfeitdocument, and/or a document that includes forged contents). For example,the machine learning program may be trained using images of multipleother documents, and fraud determinations made in connection with thoseother documents. The machine learning program may learn which rangesand/or tolerances for dimensions, fonts, colors, patterns, etc., tend tobe most indicative of counterfeiting, for example. A forgery may bedetected based upon factors relating to the contents of various fieldsin a document, such as whether handwriting, a signature, and/or a dateformat (e.g., “Jan. 1, 2016,” “1/1/16,” etc.) matches that used forother personal checks from a particular account holder, for example. Thefraud determination may be made substantially in real-time to provide awarning, if needed, to a merchant making a sale, for example, or may beused to flag a relatively small number of documents for physical reviewat a later time, etc.

In another exemplary embodiment, machine learning techniques may be usedto analyze financial transactions for purposes of classifyingpotentially fraudulent behavior (e.g., “counterfeiting,” “skimming,”“lost or stolen card,” etc.). For example, the machine learning programmay be trained using fraud classifications made in connection withmultiple other financial accounts. The machine learning program maylearn which types of data tend to be indicative of differentclassifications (e.g., transaction amount, credit card information entrymode, particular types of online activity data, etc.), and/or which datavalues tend to be indicative of different classifications (e.g.,transactions over $10,000, manual card number entry, etc.), for example.Once a class of potential fraud has been identified for a particulartransaction, the classification may be used to facilitate or guide afurther, more in-depth analysis or investigation. Alternatively, or inaddition, the classification may be used to calculate one or moremetrics indicating the prevalence of that type of fraud.

By replacing conventional processing techniques with one or more of theprocessing techniques described herein, problems that have beset thefield of fraud detection, classification and/or prevention in the pastmay be greatly mitigated or eliminated. For example, information thathas conventionally been overlooked or ignored may be used to moreaccurately detect, prevent and/or classify fraud, and/or to reduce falsepositive fraud alerts. As another example, a significant amount of timemay be saved by removing the need for manual investigations, or byreducing the number of instances where manual investigations arerequired.

II. Exemplary Environment for Implementing Fraud Detection and/orClassification Processing Techniques

FIG. 1 depicts an exemplary environment 10 in which techniques for frauddetection and/or classification may be implemented, according to oneembodiment. The environment 10 may include an anti-fraud services system(AFSS) 12, a financial account management system (FAMS) 14, a cardnetwork computing system 16, a number of cardholder computing devices20, a number of merchant computing systems 22, a number of other sources24, and a network 26. It is noted that, in other embodiments and/orscenarios, the environment 10 may include more, fewer and/or differentcomponents than those shown in FIG. 1, such as any of those discussedelsewhere herein. For example, the environment 10 may include one ormore additional financial account management systems and/or card networkcomputing systems, and/or one or more of the cardholder computingdevices 20 may instead be a computing device of a holder of a non-cardaccount (e.g., a checking, savings or loan account) or an applicant fora new account (e.g., a new loan account). As another example, theenvironment 10 may include a computing system of one or moreacquiring/merchant banks, and some or all of the communications withmerchant computing systems 22 described below may instead be with theacquiring bank(s).

FAMS 14 may be associated with (e.g., owned and/or maintained by) a bankor other financial entity. For example, FAMS 14 may be a bank that actsas a card issuer associated with a particular type of card network(e.g., VISA®, Mastercard®, etc.), and/or an entity that provides loans(e.g., mortgage, home equity, vehicle, etc.), saving/checking accountservices, and/or other financial services to customers. FAMS 14 maymaintain an account records database 30 that stores various kinds ofaccount information, including account holder information (e.g., names,addresses, etc.) and data indicative of financial transactions made inconnection with each account (e.g., dates, amounts and merchants forcredit or debit card transactions, dates and amounts for customerdeposits and withdrawals, etc.). Account records database 30 may storeaccount information for some or all of the cardholders associated withcardholder computing devices 20, for example. While shown in FIG. 1 as asingle entity within FAMS 14, it is understood that account recordsdatabase 30 may, in some embodiments, be distributed across multipledatabases and/or multiple physical/hardware memories, and/or may bewholly or partially external to (e.g., remote from) FAMS 14.

AFSS 12 may generally provide services that help to detect and/orclassify fraudulent activity in connection with existing and/orpotential (e.g., applied for) financial accounts, such as the accountsmanaged by FAMS 14. In some embodiments, AFSS 12 is included within FAMS14. As seen in FIG. 1, AFSS 12 may include a network interface 32, amemory 34, and a fraud detection/classification unit 36.

Network interface 32 may include hardware, firmware and/or softwareconfigured to enable AFSS 12 to wirelessly exchange electronic data withone or more other components of environment 10 via network 26. Forexample, network interface 32 may include an Ethernet port, a modem, arouter, and/or one or more other ports and/or transceivers for one ormore other wired and/or wireless communication technologies.

Memory 34 may be a computer-readable, non-transitory storage unit ordevice, or collection of units/devices, and may include persistent(e.g., hard disk) and/or non-persistent memory components. Memory 34 maystore instructions that are executable on one or more processors of AFSS12 (not shown in FIG. 1) to perform various operations, including theinstructions of various software applications and data generated and/orused by such applications.

Card network computing system 16 may be a computing system (e.g., one ormore servers) of a credit and/or debit card network entity, such asVISA® or Mastercard®, for example. In some embodiments and/or scenarioswhere the card network entity also acts as the issuer (e.g., AmericanExpress® or Discover®), card network computing system 16 may includeFAMS 14. Card network computing system 16 may provide various servicesto FAMS 14 and/or AFSS 12. For example, card network computing system 16may provide electronic updates to chargeback rules, fraud scores forparticular customers and/or transactions, and so on.

Each of cardholder computing devices 20 may be a computing device of arespective holder of a credit or debit card account managed by FAMS 14.For example, one or more of cardholder computing devices 20 may bedesktop computers, laptop computers, tablet computers, smartphones,smart watches, and so on. The cardholders (e.g., credit or debit cardaccount holders) may use cardholder computing devices 20 to access(e.g., view, modify, etc.) their account information stored in accountrecords database 30 online via network 26. In some embodiments whereAFSS 12 detects and/or classifies activity not related to credit ordebit card fraud (e.g., a fraudulent application for a home equity loan,etc.), cardholder computing devices 20 may instead be computing devicesof other types of customers or potential customers, such as holders ofnon-card-based accounts, or individuals who have submitted an onlineapplication for a loan, etc., as discussed further below. In some ofthese embodiments, the environment 10 may omit card network computingsystem 16.

Each of merchant computing systems 22 may include one or more computingdevices associated with a particular provider of products and/orservices. For example, some or all of merchant computing systems 22 mayinclude servers associated with online retailers. Alternatively, oradditionally, some or all of merchant computing systems 22 may includepoint-of-sale terminal devices providing credit and/or debit cardpayment processing features for “card present” transactions. In someembodiments where AFSS 12 detects and/or classifies activity not relatedto customer purchases (e.g., if AFSS 12 only detects loan applicationfraud, etc.), the environment 10 may omit merchant computing systems 22.

The other sources 24 may include computing devices and/or systemsassociated with sources of one or more other types of information. Forexample, other sources 24 may include vehicle telematics systems (e.g.,installed in vehicles of cardholders associated with cardholdercomputing devices 20), one or more Internet service providers (ISPs)(e.g., ISPs providing Internet access to some or all cardholders),“smart home” system devices (e.g., installed in homes of some or allcardholders), and/or other systems/devices. In some embodiments, theenvironment 10 does not include the other sources 24.

Network 26 may communicatively couple some or all of the componentsshown in FIG. 1. For example, FAMS 14 may use network 26 to communicatewith AFSS 12, card network computing system 16, cardholder computingdevices 20 and/or merchant computing systems 22. As another example,AFSS 12 may use network 26 to communicate with FAMS 14, card networkcomputing system 16, cardholder computing devices 20, merchant computingsystems 22 and/or one or more of the other sources 24. While shown as asingle entity in FIG. 1, network 26 may include multiple communicationnetworks of one or more types (e.g., one or more wired and/or wirelesslocal area networks (LANs), and/or one or more wired and/or wirelesswide area networks (WANs) such as the Internet). Moreover, network 26may use partially or entirely distinct network components to supportcommunications between different endpoints or computing devices, such aswireless communication or data transmission over one or more radiofrequency links and/or wireless communication channels. For example, theportion(s) of network 26 used for communications between FAMS 14 andAFSS 12 may be the same as, or different than, the portion(s) of network26 used for communications between FAMS 14 and one or more of cardholdercomputing devices 20 over one or more radio links or wirelesscommunication channels, or between AFSS 12 and one or more of the othersources 24, etc. Those skilled in the art will appreciate differenttypes of networks that are appropriate for network 26, depending upon,for example, how AFSS 12, FAMS 14 and/or other components of environment10 are localized or distributed across a relatively large geographicarea.

Generally, fraud detection/classification unit 36 of AFSS 12 may detectfraudulent activity, confirm whether suspected or reported fraudulentactivity is truly fraudulent, and/or classify fraudulent or suspectedfraudulent activity. For example, fraud detection/classification unit 36may analyze each transaction stored in account records database 30 todetermine whether that transaction is, or potentially is, fraudulent.Alternatively, fraud detection/classification unit 36 may analyze onlythose transactions that were flagged as possibly being fraudulent (e.g.,by a cardholder calling in to report an unauthorized and/or unrecognizedtransaction, or by FAMS 14 or AFSS 12 generating a preliminary fraudalert after applying an initial set of rules to a transaction, etc.).Fraud detection/classification unit 36 may also, or instead, supportadditional functionality, such as that described below in connectionwith the various components of fraud detection/classification unit 36shown in FIG. 1.

As seen in FIG. 1, fraud detection/classification unit 36 may include amachine learning (ML) rule generator 40, an external data collectionunit 42, a behavior analysis unit 44, a dispute resolution unit 46, achargeback analysis unit 50, an image analysis unit 52, a classificationunit 54, and/or a notification unit 56. In other embodiments, frauddetection/classification unit 36 may include more, fewer and/ordifferent components/units than those shown in FIG. 1. In someembodiments, each of ML rule generator 40, external data collection unit42, behavior analysis unit 44, dispute resolution unit 46, chargebackanalysis unit 50, image analysis unit 52, classification unit 54,notification unit 56, and/or other units or components of frauddetection/classification unit 36 may be a software component stored inmemory 34 and implemented by one or more processors of one or morecomputing devices (e.g., servers) included in AFSS 12.

ML rule generator 40 may generally analyze various types of data togenerate and/or update fraud detection and/or classification rules to beapplied by fraud detection/classification unit 36 and stored in an MLrules database 58. As discussed in further detail below, the rules maybe used to detect and/or classify a single type or category offraudulent activity, or may be used broadly in connection with multipletypes or categories of fraudulent activity. ML rule generator 40 mayimplement any suitable type or types of machine learning. For example,ML rule generator 40 may implement supervised learning techniques, suchas decision trees, regression-based models, support vector machines(SVMs) and/or neural networks, and/or unsupervised learning techniquessuch as Dirichlet process mixture models and/or k-means clustering.Other machine learning techniques are also possible, such as techniquesutilizing Bayesian networks, “deep learning” techniques, and so on.While shown in FIG. 1 as a single entity within AFSS 12, it isunderstood that ML rules database 58 may, in some embodiments, bedistributed across multiple databases and/or multiple physical/hardwarememories, and/or may be wholly or partially external to (e.g., remotefrom) AFSS 12.

External data collection unit 42 may generally collect, via networkinterface 32 and/or from sources internal to AFSS 12, information fromvarious sources (e.g., FAMS 14, cardholder computing devices 20, othersources 24, etc.), and provide that data to other portions of AFSS 12 asneeded (e.g., to ML rule generator 40 to generate and/or update rules,and/or to behavior analysis unit 44, dispute resolution unit 46,chargeback analysis unit 50, image analysis unit 52 and/orclassification unit 54 to detect and/or classify fraudulent activity).Some data may be collected indirectly. For example, FAMS 14 may collecttransaction data from merchant computing systems 22 (and/or fromacquiring banks associated with one or more of merchant computingsystems 22), and external data collection unit 42 may then collect thatdata from the account records database 30 of FAMS 14.

Once an initial set of rules has been generated and stored in ML rulesdatabase 58, those rules may dictate some or all of the types of datagathered by external data collection unit 42. In some embodiments,however, external data collection unit 42 collects a broad set of datatypes that may or may not be relevant to fraud determination orclassification, and ML rule generator 40 continually analyzes that datato determine which data types are most predictive of fraud and/or fraudtype/class.

Behavior analysis unit 44 may generally analyze cardholder-related (orother customer-related) information to identify patterns of behavior,which may then be used by fraud detection/classification unit 36 todetect and/or classify fraudulent activity. For example, behavioranalysis unit 44 may analyze information obtained from account recordsdatabase 30 to identify spending patterns associated with differentcardholders. The operation of behavior analysis unit 44, including thetypes of information analyzed and the ways in which that information isused to arrive at a result (e.g., a pattern of behavior), may bedictated by the rules stored in ML rules database 58.

Data indicative of the behavior patterns identified by behavior analysisunit 44 may be stored in an account holder behaviors database 60, forexample. While shown in FIG. 1 as a single entity within AFSS 12, it isunderstood that account holder behaviors database 60 may, in someembodiments, be distributed across multiple databases and/or multiplephysical/hardware memories, and/or may be wholly or partially externalto (e.g., remote from) AFSS 12. In one embodiment, for example, accountholder behaviors database 60 may be included within account recordsdatabase 30. In still other embodiments, the environment 10 may notinclude account holder behaviors database 60, and behavior patterns maybe only identified by behavior analysis unit 44 “on the fly” as neededby fraud detection/classification unit 36 (e.g., when needed to analyzea transaction in view of past spending patterns of a particularcardholder, etc.).

In some embodiments, behavior analysis unit 44 may separately analyzethe transactions associated with each account holder, even if more thanone account holder exists for a particular account. For example,behavior analysis unit 44 may independently analyze the transactions ofeach cardholder for a credit or debit card account in which each spousehas been issued a credit or debit card in his or her name. Frauddetection/classification unit 36 may then utilize the individualspending patterns when detecting and/or classifying fraud. In oneembodiment where fraud detection/classification unit 36 utilizes adollar amount threshold to detect likely fraudulent transactions, forexample, a first threshold may be used for transactions made by a firstcardholder listed on an account, and a higher, second threshold may beused for transactions made by a second cardholder listed on the account.Further examples are provided below in connection with FIG. 6, accordingto various embodiments. In this manner, fraud detection and/orclassification may be made more precise than would be the case ifspending patterns were only identified at the aggregate level (e.g.,using a single dollar amount threshold, regardless of which cardholdermade a particular transaction).

Dispute resolution unit 46 may generally analyze financial transactiondata and/or other information to automatically generate queries forcardholders or other customers. For example, dispute resolution unit 46may analyze information obtained from account records database 30. Thegenerated queries may be designed to help fraud detection/classificationunit 36 determine whether a particular transaction was fraudulent, orestimate a probability that the transaction was fraudulent, etc. Disputeresolution unit 46 may also process responses fromcardholders/customers, and automatically generate additional queriesbased upon those responses. Examples of the operation of disputeresolution unit 46 are provided below in connection with FIGS. 4E and 9,according to various embodiments.

Chargeback analysis unit 50 may generally analyze financial transactionand/or other information to identify transactions that are goodcandidates for chargeback payments. For example, chargeback analysisunit 50 may analyze information obtained from account records database30 to determine whether there is a relatively high probability that themerchant (or an acquiring bank) should be responsible for a chargebackpayment to a card issuer associated with FAMS 14. The operation ofchargeback analysis unit 50, including the types of information analyzedand the ways in which that information is used to arrive at a result(e.g., flagging a transaction as a chargeback candidate), may bedictated by the rules stored in ML rules database 58. ML rule generator40 may make use of chargeback rules obtained from a card network entity(e.g., from card network computing system 16), and stored in chargebackrules database 62, to generate and/or update the rules applied bychargeback analysis unit 50. Examples of the operation of chargebackanalysis unit 50 are provided below in connection with FIGS. 4B and 7,according to various embodiments.

In some embodiments, transactions flagged by chargeback analysis unit 50are subject to further, manual review using the chargeback rules storedin chargeback rules database 62. In other embodiments, chargebackanalysis unit 50 (or another component of fraud detection/classificationunit not shown in FIG. 1) automatically, with little or no manualinput/assistance, applies the chargeback rules from chargeback rulesdatabase 62 for each flagged transaction. While shown in FIG. 1 as asingle entity within AFSS 12, it is understood that chargeback rulesdatabase 62 may, in some embodiments, be distributed across multipledatabases and/or multiple physical/hardware memories, and/or may bewholly or partially external to (e.g., remote from) AFSS 12.

Image analysis unit 52 may generally analyze image data corresponding tophysical documents to identify fraudulent (e.g., counterfeit and/orforged) documents, and/or to flag potentially fraudulent documents forfurther (e.g., manual) review. For example, image analysis unit 52 mayanalyze information obtained from merchant computing systems 22 todetermine whether there is a relatively high probability that documentspresented to the merchants (e.g., personal checks, identification cards,etc.) are fraudulent. Image analysis unit 52 may be configured toanalyze only a single type of document, or multiple types of documents.The operation of image analysis unit 52, including the imagecharacteristics analyzed and the ways in which the characteristics maybe used to arrive at a result (e.g., flagging a document as potentiallyfraudulent), may be dictated by the rules stored in ML rules database58. Examples of the operation of image analysis unit 52 are providedbelow in connection with FIGS. 4F and 10, according to variousembodiments.

Classification unit 54 may generally analyze broad categories of datafrom various sources (e.g., account records database 30, cardholdercomputing devices 20, merchant computing systems 22, and/or othersources 24) to categorize/classify types of suspected fraudulentfinancial activity. Classification unit 54 may classify fraudulentactivity only within a particular subset of fraudulent financialactivity (e.g., classifying debit and/or credit card transactions asinvolving a potential case of counterfeiting, skimming, lost/stolen carduse, chargeback fraud, etc.), or may classify fraudulent financialactivity across a broader spectrum (e.g., including types of identitytheft not necessarily tied to a single financial transaction, such asapplication fraud). In some embodiments, classification unit 54classifies suspected fraudulent activity in connection with a particularaccount or transaction in response to being notified of suspect activity(e.g., notified by another component of fraud detection/classificationunit 36, or by a manual user input, etc.). In other embodiments,classification unit 54 itself (or another component of frauddetection/classification unit 36) identifies suspect activity beforeclassification unit 54 classifies that activity. Examples of theoperation of classification unit 54 are provided below in connectionwith FIGS. 4C and 11, according to various embodiments.

Notification unit 56 may generally provide alerts, confirmations, and/orother notifications to various individuals (e.g., customers, bankemployees associated with FAMS 14, third party employees associated withAFSS 12, etc.). For example, notification unit 56 may generate anotification message stating that a fraud alert associated with aparticular transaction is a false positive, and cause network interface32 to send the message to a computer terminal or to FAMS 14 for displayto a system user. As another example, notification unit 56 may causenetwork interface 32 to send other flagged transactions and/or documents(e.g., chargeback candidates identified by chargeback analysis unit 50,documents that image analysis unit 52 has identified as potentiallyfraudulent, etc.) to a computer terminal or FAMS 14 for display to asystem user. As yet another example, notification unit 56 may causenetwork interface 32 to send queries generated by dispute resolutionunit 46 to various ones of cardholder computing devices 20 for displayto cardholders.

The operation of various components of the environment 10 shown in FIG.1, according to different embodiments and/or scenarios, will bedescribed further below in connection with the remaining figures.

III. Exemplary Process Flows for Machine Learning of Fraud Detectionand/or Classification Rules

As discussed above, ML rule generator 40 may generate and/or updaterules that are used for one or more of a variety of different purposesrelating to fraud detection and/or classification. FIG. 2 depicts onegeneralized, example process flow 80 for machine learning that may beimplemented by ML rule generator 40, and possibly one or more othercomponents of fraud detection/classification unit 36.

In the process flow 80, multi-account data 82 may represent dataassociated with multiple financial accounts, each with one or moreaccount holders. The financial accounts may be existing or potentialaccounts, and the account holders may include holders of accounts and/orpotential holders of potential accounts. For example, the multi-accountdata 82 may include existing and/or applied-for credit card accounts,debit card accounts, savings accounts, checking accounts, investmentaccounts, loan accounts, etc.

Depending upon the embodiment, the multi-account data 82 may include oneor more different types of information obtained (e.g., by external datacollection unit 42 of FIG. 1) from one or more of FAMS 14, cardholdercomputing devices 20, merchant computing systems 22, and/or othersources 24. For example, the multi-account data 82 may includetransaction data (e.g., transaction dates, amounts, locations, etc.)from account records database 30 of FAMS 14, data indicative of InternetProtocol (IP) addresses of cardholder computing devices 20 and/ordevices in merchant computing systems 22, Internet browsing and/orsearch history data from cardholder computing devices 20 (or from an ISPcomputer system included in other sources 24, etc.), vehicle telematicsdata from telematics systems of cardholder vehicles, home occupancyand/or usage data (e.g., smart appliance data) from smart home systemsof cardholders, autonomous or smart vehicle data, vehicle navigationsystem data, mobile device data, mobile device and/or vehicle GPS data,and/or one or more other types of data. In some embodiments, themulti-account data 82 only includes data that account holders orpotential account holders have expressly consented to share with anentity associated with FAMS 14 and/or AFSS 12 (e.g., in exchange forfraud protection services). In certain other embodiments, however,express consent is only needed for certain types of information, such asbrowsing history information, vehicle telematics data, etc.

The multi-account data 82 may be associated with multiple frauddetermination labels. The labels may simply reflect whether or not fraudexisted (e.g., “fraud” or “no fraud”), or may also indicate a type orclass of fraud (e.g., “counterfeiting,” “lost or stolen card use,”etc.), for example. In one embodiment, each of a number of data sets inthe multi-account data 82 is associated with such a label, and includesdata relating to a particular financial transaction, financial account,loan application, etc., for which the fraud determination was made(e.g., after a manual and/or automated fraud investigation). The labelsmay include final fraud determinations that were made via earlieriterations of the process flow 80, and/or external to the process flow80.

To provide a more detailed example, a first data set associated with a“card present” credit card transaction may include data describing thattransaction (e.g., from account records database 30) and data indicativeof the cardholder's online browsing activity (e.g., from one ofcardholder computing devices 20) for the 15 days immediately precedingthe transaction, and be labeled “confirmed fraud.” A second data set,associated with another “card present” transaction (for the sameaccount, or for a different account), may include the same general typesof data but be labeled “no fraud,” and so on. In some embodiments and/orscenarios, the same data may appear in, or be used by, two or more ofthe data sets. If the two “card present” transactions described aboveare both associated with the same account, for example, and if thesecond transaction occurred less than 15 days after the firsttransaction, some of the same online activity data may be shared by thefirst and second data sets.

At a process stage 84, the multi-account data 82 may be analyzed togenerate fraud detection and/or classification rules (e.g., to be storedin ML rules database 58). Any suitable type of supervised machinelearning program/technique(s) may be used, such as SVMs, neuralnetworks, logistic regression, etc. Generally, process stage 84 mayserve to identify which type(s) of data is/are probative of whetherfraud has occurred (and/or the type/category of fraud that may haveoccurred), and to determine the data values and/or combinations that areprobative of whether fraud has occurred (and/or the type/category offraud that may have occurred). By analyzing many (e.g., thousands) ofpositively and negatively labeled data sets in the multi-account data82, for example, process stage 84 may learn that certain spendingpatterns within a threshold time of a transaction tend to indicate thatthe cardholder made the transaction (e.g., thereby indicating that fraudhas not occurred, or that a fraud report is itself fraudulent ormistaken, etc.), that certain types of online searches by a cardholder(e.g., including a descriptor of a product purchased in the transaction,or a name of the merchant, etc.) tend to indicate that the cardholdermade the transaction, that the cardholder's distance from the site of a“card present” transaction (e.g., as determined from GPS informationprovided by the cardholder's smartphone, wearable electronics, orvehicle) relates to the probability of fraudulent activity according toa particular equation, and so on. Other specific examples of such rules,and how those rules may be generated, are discussed below in connectionwith FIGS. 3A-3F and 4A-4F, according to various embodiments.

At process stage 86, the rules generated or updated at process stage 84may be applied to first account data 90 associated with a particularaccount and customer(s) (e.g., a customer associated with a particularone of computing devices 20). The types of data included in firstaccount data 90 may depend upon which types of data were determined, byprocess stage 84, to be relevant to a fraud determination. For example,if the rules give weight to the amount and date of a financialtransaction when determining whether the transaction is fraudulent, andalso give weight to whether the account holder visits a particular typeof website, then the first account data 90 may include the amount anddate of one or more transactions, as well as data indicative of visitedweb sites (e.g., Uniform Resource Locators (URLs) and/or content ofvisited websites, etc.). The first account data 90 may includeinformation obtained (e.g., by external data collection unit 42) fromone or more of FAMS 14, one of cardholder computing devices 20associated with the customer holding the first account, one or more ofmerchant computing systems 22, and/or one or more of other sources 24,for example.

Process stage 86 may output various different types of information,depending upon the embodiment and/or scenario. For example, dependingupon the content of first account data 90 and the rules generated orupdated at process stage 84, process stage 86 may generate dataindicating that a particular financial transaction associated with firstaccount data 90 is, or is not, fraudulent or potentially fraudulent.Alternatively, or additionally, process stage 86 may generate dataindicating a particular classification for fraudulent or suspectedfraudulent activity (e.g., a fraudulent transaction) associated withfirst account data 90.

In some embodiments, further analysis (e.g., a manual review, or furtherautomated review using additional data sources, etc.) may be performedat an additional stage, shown in dashed lines in FIG. 2 as process stage92. The additional analysis may then be used to make a final frauddetermination (e.g., a final decision on whether fraud occurred, and/oron the type of fraud that occurred) at process stage 94. In otherembodiments, process stage 92 is omitted from process flow 80, andprocess stage 94 merely represents the output of process stage 86. Thefinal determination made at process stage 94, along with the firstaccount data 90 used to make that determination, may be fed back intoprocess stage 84 to provide additional labeled data for purposes ofupdating the rules.

In some embodiments, the process flow 80 includes more, fewer and/ordifferent stages, such as any of those discussed elsewhere herein (e.g.,in connection with FIGS. 3A-3F). In one alternative embodiment, processstages 84 and 86 may be combined. For example, the multi-account data 82may be unlabeled rather than labeled (or the labels may be ignored), andthe combined process stage 84, 86 may use unsupervised learningtechniques (e.g., clustering techniques) to classify anomalous/outlierfinancial transactions, accounts, applications, etc., as “suspect” andneeding further analysis.

More specific, machine learning-based process flows generallycorresponding to process flow 80 of FIG. 2 will now be described withreference to FIGS. 3A-3F. It is noted, however, that other process flowsare also within the scope of the invention described herein. Moreover,while FIGS. 3A-3F generally correspond to embodiments in whichsupervised machine learning techniques are used, other embodiments mayinstead use unsupervised machine learning techniques, as noted above. Invarious different embodiments, fraud detection/classification unit 36may be configured to implement only one of the process flows of FIGS.3A-3F, or may be configured to implement two or more (e.g., all) of theprocess flows shown in FIGS. 3A-3F.

A. Exemplary Process Flow for Machine Learning of Fraud Detection RulesUsing Online Activity Data

Referring first to FIG. 3A, an exemplary process flow 100 may generallybe used to detect fraud using customer online activity data. In theprocess flow 100, multi-customer online activity data 102 may representdata associated with the online activities of a number (e.g., thousands)of customers (e.g., credit or debit cardholders, checking or savingaccount holders, etc.). The multi-customer online activity data 102 mayinclude data indicating actions that the customers took, and/or websites visited by the customers, while the customers were connected tothe Internet via web browsers (e.g., executing on respective ones ofcardholder computing devices 20). For example, the multi-customer onlineactivity data 102 may include URLs of, and/or content (e.g., text)within, web sites visited by customers, search terms entered bycustomers using search engine tools, search results presented tocustomers by search engine tools, indications of interactive controls(e.g., virtual buttons) selected by customers on various web pages, andso on.

The multi-customer online activity data 102 may include data obtained(e.g., by external data collection unit 42 of FIG. 1) from cardholdercomputing devices 20, from one or more ISPs of other sources 24, and/orfrom a third party aggregator of such information, for example. In someembodiments, the multi-customer online activity data 102 may onlyinclude data that customers have expressly consented to share with anentity associated with FAMS 14 and/or AFSS 12 (e.g., in exchange forfraud protection services or other benefits, such as discounts).

As described above in connection with multi-account data 82 of processflow 80, the multi-customer online account data 102 may be associatedwith multiple fraud determination labels. In some embodiments, eachlabel may be associated with a data set that includes not only thecorresponding portion of multi-customer online activity data 102, butalso one or more other types of data, such as transaction data (e.g.,transaction dates, amounts, locations, etc.) for each customer fromaccount records database 30 of FAMS 14, data indicative of IP addressesof cardholder computing devices 20 and/or devices in merchant computingsystems 22, Internet browsing and/or search history data from cardholdercomputing devices 20 (or from an ISP computer system included in othersources 24, etc.), vehicle telematics data from telematics systems ofother sources 24, home occupancy and/or usage data (e.g., smartappliance data) from smart home systems of other sources 24, and so on.The labels may include final fraud determinations that were made viaearlier iterations of the process flow 100, and/or external to theprocess flow 100. Multi-customer online account data 102 may includemany (e.g., thousands) of positively and negatively labeled data sets.

At a process stage 104, the multi-customer online activity data 102 maybe analyzed to generate fraud detection rules (e.g., to be stored in MLrules database 58). As described above in connection with process stage84 of process flow 80, any suitable type of supervised machine learningprogram/technique(s) may be used. Generally, process stage 104 may serveto identify which type(s) of online activity data is/are probative ofwhether fraud has occurred, and to determine the data values and/orcombinations that are probative of whether fraud has occurred. While notshown in FIG. 3A, the fraud detection rules may not only detect fraud,but also classify fraud (e.g., as described below in connection withFIG. 3C), in some embodiments.

At process stage 106, the rules generated or updated at process stage104 may be applied to first customer online activity data 110. The firstcustomer online activity data 110 may be associated with a particularcustomer, such as a customer associated with a particular one ofcomputing devices 20, for example. The types of data included in firstcustomer online activity data 110 may depend upon which types of onlineactivity data were determined, by process stage 104, to be relevant to afraud determination. For example, the first customer online activitydata 110 may include information obtained (e.g., by external datacollection unit 42) from one of cardholder computing devices 20 (i.e.,the device associated with the first customer), and/or from an ISP ofother sources 24. Some specific examples of rules that may be generatedby process stage 104, and applied at process stage 106, are describedbelow in connection with FIG. 4A.

Process stage 106 may output various different types of information,depending upon the embodiment and/or scenario. For example, dependingupon the content of first customer online activity data 110 and therules, process stage 106 may generate data indicating that a particularfinancial transaction associated with the first customer is, or is not,fraudulent or potentially fraudulent. Alternatively, or additionally,process stage 106 may generate data indicating a particularclassification of fraudulent or potentially fraudulent activityassociated with first customer online activity data 110.

In some embodiments, further analysis (e.g., a manual review, or furtherautomated review using additional data sources, etc.) is performed at anadditional stage, shown in dashed lines in FIG. 3A as process stage 112.The additional analysis may then be used to make a final frauddetermination (e.g., a final decision on whether fraud occurred, and/oron the type of fraud that occurred) at process stage 114. In otherembodiments, process stage 112 is omitted from process flow 100, andprocess stage 114 merely represents the output of process stage 106.

The final determination made at process stage 114, along with the firstcustomer online activity data 110 (and any other data) used to make thatdetermination, may be fed back into process stage 104 to provideadditional labeled data for purposes of updating the rules. In someembodiments, a preliminary fraud determination made at process stage 106is also fed back into process stage 104, to allow the machine learningprogram to determine and improve upon past performance/accuracy.

B. Exemplary Process Flow for Machine Learning of Chargeback CandidateDetection Rules

Referring next to FIG. 3B, an exemplary process flow 120 may generallybe used to identify the financial transactions for which chargebacks(e.g., post-transaction payments from merchants, or acquiring/merchantbanks, back to the issuer to return proceeds from transactions) areappropriate. In the process flow 120, multi-account transaction data 122may represent data associated with the financial transactions involvingthe accounts of a number (e.g., thousands) of credit or debitcardholders. The multi-account transaction data 122 may includeinformation such as transaction dates, transaction amounts, merchantnames (and/or aliases) associated with the transaction, informationrelating to how the card information was collected by the merchant(e.g., by swiping, an EMV chip reader, manual entry of the card number,etc.), geographic locations of “card present” transactions, and so on.The multi-account transaction data 122 may include data obtained (e.g.,by external data collection unit 42 of FIG. 1) from merchant computingsystems 22 and/or from acquiring/merchant banks associated with thosemerchants, for example.

Similar to the labels described above in connection with multi-accountdata 82 of process flow 80, the multi-account transaction data 122 maybe associated with multiple chargeback outcome labels. For example, eachlabel may be associated with a data set that includes the correspondingportion of multi-account transaction data 122. The outcome labels mayinclude final chargeback determinations that were made (in connectionwith the transactions represented in multi-account transaction data 122)via earlier iterations of the process flow 120, and/or external to theprocess flow 120. Multi-account transaction data 122 may include many(e.g., thousands) of positively and negatively labeled data sets.

At a process stage 124, the multi-account transaction data 122 may beanalyzed to generate chargeback candidate detection rules (e.g., to bestored in ML rules database 58). As described above in connection withprocess stage 84 of process flow 80, any suitable type of supervisedmachine learning program/technique(s) may be used. Generally, processstage 124 may serve to identify which type(s) of transaction data is/areprobative of whether, under the full chargeback rules of the cardnetwork entity, a chargeback is appropriate for a given transaction.Process stage 124 may also determine the transaction data values and/orcombinations that are probative of whether a chargeback is appropriatefor the transaction.

At a process stage 126, the rules generated or updated at process stage124 may be applied to first account transaction data 130 to determinewhether a transaction associated with the first account is a “good”chargeback candidate. Put differently, process stage 126 may, instead ofapplying the full chargeback rules of the card network entity (which maybe quite lengthy and complex) to the facts surrounding the transaction,use various factors and algorithms developed at process stage 124 todetermine whether there exists a relatively high probability that achargeback would be appropriate for the transaction if the fullchargeback rules were applied. The process stage 126 may calculate apercentage probability that the transaction is one in which a chargebackis appropriate, for example.

The first account transaction data 130 may be associated with theaccount of a particular cardholder or cardholders, such as a cardholderassociated with a particular one of cardholder computing devices 20, forexample. The types of data included in first account transaction data130 may depend upon which types of transaction-related data weredetermined, by process stage 124, to be relevant to a chargebackcandidate determination. For example, the first account transaction data130 may include information obtained (e.g., by external data collectionunit 42) from one of merchant computing systems 22 (e.g., the computingsystem of the merchant involved in the transaction being analyzed)and/or from an acquiring/merchant bank associated with that merchant.The first account transaction data 130 may also include informationabout one or more other transactions associated with the first account(e.g., data pertaining to other transactions occurring shortly beforeand/or after the transaction at issue). Some specific examples of rulesthat may be generated by process stage 124, and applied at process stage126, are described below in connection with FIG. 4B.

Process stage 126 may output information indicating whether theparticular transaction represented by first account transaction data 130is a “good” candidate for chargeback detection. For example, processstage 126 may output a percentage probability, calculated according tothe rules generated or updated at process stage 124, that thetransaction is one in which a chargeback is appropriate. As anotherexample, process stage 126 may output a binary indicator of whether thetransaction is, or is not, a strong/likely chargeback candidate (e.g.,by comparing the percentage probability to a threshold probability).

If the transaction is identified as a chargeback candidate at processstage 126, the full chargeback rules of the card network entity may beapplied at a process stage 132. Process stage 132 may include manualapplication of the full chargeback rules, and/or automated applicationof the full chargeback rules, in various different embodiments. Basedupon the analysis at process stage 132, a final chargeback determinationmay be made at a process stage 134. The final determination made atprocess stage 134, along with the first account transaction data 130(and any other data) used to make that determination, may be fed backinto process stage 124 to provide additional labeled data for purposesof updating the rules. In some embodiments, the indication of whetherthe transaction is a good chargeback candidate generated at processstage 126 may also be fed back into process stage 124, to allow themachine learning program to determine and improve upon pastperformance/accuracy.

C. Exemplary Process Flow for Machine Learning of Fraud ClassificationRules

Referring now to FIG. 3C, an exemplary process flow 140 may generally beused to classify instances of suspected or potential fraud. For example,the process flow 140 may represent ongoing, real-time or batchprocessing of a large amount of data associated with a large number ofpotential and/or existing financial accounts (e.g., all accountsassociated with a particular bank, or all accounts opting in to a fraudprotection program, etc.). In this manner, the process flow 140 may beused to initially flag situations for closer investigation, and provideone or more classifications of the type(s) of fraud potentially at issuein order to narrow or otherwise facilitate the investigation. In otherembodiments, the process flow 140 may be used to provide a narrowerclassification (e.g., “skimming”) when a broader class of fraud (e.g.,credit card fraud) is already suspected.

In the process flow 140, multi-account data 142 may represent dataassociated with financial accounts of a number (e.g., thousands) ofaccount holders. The financial accounts may be existing or potentialaccounts, and the account holders may include holders of accounts and/orpotential holders of potential accounts. For example, the multi-accountdata 142 may include existing and/or applied-for credit card accounts,debit card accounts, savings accounts, checking accounts, investmentaccounts, loan accounts, etc.

Depending upon the embodiment, the multi-account data 142 may includeone or more different types of information obtained (e.g., by externaldata collection unit 42 of FIG. 1) from one or more of FAMS 14,cardholder computing devices 20, merchant computing systems 22, and/orother sources 24. For example, the multi-account data 142 may includetransaction data (e.g., transaction dates, amounts, locations, etc.)from account records database 30 of FAMS 14, data indicative of IPaddresses of cardholder computing devices 20 and/or devices in merchantcomputing systems 22, Internet browsing and/or search history data fromcardholder computing devices 20 (or from an ISP computer system includedin other sources 24, etc.), vehicle telematics data from telematicssystems of cardholder vehicles, home occupancy and/or usage data (e.g.,smart appliance data) from smart home systems of cardholders, and/or oneor more other types of data. Some or all data within multi-account data142 may be information that account holders or potential account holdershave expressly consented to share with an entity associated with FAMS 14and/or AFSS 12 (e.g., in exchange for fraud protection services).

The multi-account data 142 may be associated with multiple frauddetermination labels, each indicating a type or class of fraud (e.g.,“counterfeiting,” “lost or stolen card use,” “skimming,” “chargebackfraud,” “application fraud,” etc.), or indicating a lack of fraud, forexample. In one embodiment, each of a number of data sets in themulti-account data 142 is associated with at least one suchclassification/label, and includes data relating to a particularfinancial transaction, financial account, loan application, etc., forwhich the fraud classification or classifications was/were made (e.g.,after a previous iteration of process flow 140, or after another manualand/or automated fraud investigation). Multi-account data 142 mayinclude many (e.g., thousands) of data sets labeled with various knownfraud classifications.

At a process stage 144, the multi-account data 142 may be analyzed togenerate fraud classification rules (e.g., to be stored in ML rulesdatabase 58). As described above in connection with process stage 84 ofprocess flow 80, any suitable type of supervised machine learningprogram/technique(s) may be used. Generally, process stage 144 may serveto identify which type(s) of transaction data is/are probative of theparticular type of fraud (if any) that has occurred. Process stage 144may also determine the data values and/or combinations that areprobative of the particular type of fraud (if any) that has occurred.

At a process stage 146, the rules generated or updated at process stage144 may be applied to first account data 150. The first account data 150may be associated with a particular account and a particular customer(e.g., a cardholder associated with a particular one of computingdevices 20). The types of data included in first account data 150 maydepend upon which types of data were determined, by process stage 144,to be relevant to fraud classification. For example, the first accountdata 150 may include information obtained (e.g., by external datacollection unit 42) from one or more of FAMS 14, one of cardholdercomputing devices 20 (i.e., the device associated with the customerholding or applying for the first account), one or more of merchantcomputing systems 22, and/or one or more of other sources 24. Somespecific examples of rules that may be generated by process stage 144,and applied at process stage 146, are described below in connection withFIG. 4C.

Process stage 146 may output data (e.g., a message or code) that is usedto classify suspected fraudulent activity (in connection with theaccount associated with first account data 150) at a process stage 152.For example, process stage 152 may assign a classification of“counterfeiting” if process stage 146 determined that the first accountdata 150 indicated a number of circumstances that, according to therules generated at process stage 144, are known to be correlated withcounterfeiting activity (e.g., two “card present” transactions occurringin different states within the same one-hour time period, etc.). In someembodiments and/or scenarios, two or more classifications mayconcurrently be assigned to first account data 150. For example, processstage 146 may determine a set of probabilities for a set of two or morepotential types of fraud, and process stage 152 may assign eachclassification, with each respective probability, to first account data150. Moreover, in some embodiments and scenarios, process stage 152 mayassign a classification that corresponds to an absence of any suspectedfraud (e.g., “no fraud”).

At a process stage 154, if process stage 152 assigned a classificationother than one indicating the absence of suspected fraud, the firstaccount data 150, and/or other information associated with the accountand the suspected class of fraud, may be analyzed in depth to make afinal fraud determination at a process stage 156. Generally, the fraudclassification may be used to facilitate the analysis at process stage154, with process stage 154 including manual and/or automated frauddetection techniques. For example, personnel associated with AFSS 12 mayuse the fraud classification(s) to inform their strategy and/or focuswith respect to conducting an in-depth fraud investigation.

The additional analysis at process stage 154 may then result in a finalfraud determination at process stage 156. The final determination mayindicate both whether fraud occurred and, if so, the class(es)/type(s)of fraud that occurred. The final determination made at process stage156, and information used to make that determination (e.g., the firstaccount data 150 and potentially other data), may be fed back intoprocess stage 144 to provide additional labeled data for purposes ofupdating the rules. In some embodiments, the (preliminary) fraudclassification made at process stage 152 may also be fed back intoprocess stage 144 to help the machine learning program identifyinstances in which the preliminary classifications at process stage 152were incorrect. Process stage 144 may then update the fraudclassification rules in ways that seek to prevent or reduce suchinstances in the future.

D. Exemplary Process Flow for Machine Learning of Application FraudDetection Rules

Referring now to FIG. 3D, an exemplary process flow 160 may generally beused to detect application fraud. “Application fraud” may generallyrefer to fraud in connection with the application for any type offinancial account, loan and/or line of credit (e.g., mortgage loan,vehicle loan, small business loan, payday loan, home equity line ofcredit, credit card account, debit card account, checking account,savings account, investment account, etc.). In some embodiments and/orscenarios, however, the application may be for non-financial purposes,such as an application for membership in a particular group orinstitution, for example.

In the process flow 160, multi-applicant search history data 162 mayrepresent data associated with the Internet search history of a number(e.g., thousands) of applicants. The multi-applicant search history data162 may include search terms entered by the applicants using onlinesearch engine tools, for example, and/or the results of such searches(e.g., URLs, titles and/or contents of search results), for example.

The multi-applicant search history data 162 may include data obtained(e.g., by external data collection unit 42 of FIG. 1) from cardholdercomputing devices 20, from one or more ISPs of other sources 24, and/orfrom a third party aggregator of such information, for example. In someembodiments, the multi-applicant search history data 162 only includesdata that the applicants have expressly consented to share with anentity associated with FAMS 14 and/or AFSS 12 (e.g., in exchange forconsideration of their applications).

As described above in connection with multi-account data 82 of processflow 80, the multi-applicant search history data 162 may be associatedwith multiple fraud determination labels. In some embodiments, eachlabel may be associated with a data set that corresponds to anapplication submitted by a particular applicant, where the data setincludes the corresponding portion of multi-applicant search historydata 162 (e.g., the search terms and/or results associated with theparticular application). The labels may include final frauddeterminations that were made via earlier iterations of the process flow160, and/or external to the process flow 160. Multi-applicant searchhistory data 162 may include many (e.g., thousands) of positively andnegatively labeled data sets.

At a process stage 164, the multi-applicant search history data 162 maybe analyzed to generate application fraud detection rules (e.g., to bestored in ML rules database 58). As described above in connection withprocess stage 84 of process flow 80, any suitable type of supervisedmachine learning program/technique(s) may be used. Generally, processstage 164 may serve to identify which type(s) of Internet search-relateddata is/are probative of whether application fraud has occurred, and todetermine the data values and/or combinations that are probative ofwhether application fraud has occurred.

At process stage 166, the rules generated or updated at process stage164 may be applied to first applicant search history data 170. The firstapplicant search history data 170 may be associated with a particularapplication and a particular applicant (e.g., a person associated with aparticular one of computing devices 20), for example. The types of dataincluded in first applicant search history data 170 may depend uponwhich types of Internet search-related data were determined, by processstage 164, to be relevant to a fraud determination. The first applicantsearch history data 170 may include information obtained (e.g., byexternal data collection unit 42) from one of computing devices 20(i.e., the device associated with the first applicant), and/or from anISP of other sources 24, for example. Some specific examples of rulesthat may be generated by process stage 164, and applied at process stage166, are described below in connection with FIG. 4D.

Process stage 166 may output information indicating whether fraud issuspected in connection with the application corresponding to firstapplicant search history data 170. For example, process stage 166 mayoutput a percentage probability, calculated according to the rulesgenerated or updated at process stage 164, that the application wasfraudulently made (e.g., by someone other than the purported applicantor an authorized representative thereof). As another example, processstage 166 may output a binary indicator of whether the applicationlikely was, or likely was not, fraudulently made (e.g., by comparing apercentage probability to a threshold probability).

In some embodiments, further analysis (e.g., a manual review, or furtherautomated review using additional data sources, etc.) is performed at anadditional stage, shown in dashed lines in FIG. 3D as process stage 172.The additional analysis may then be used to make a final frauddetermination (e.g., a final decision on whether application fraudoccurred) at process stage 174. In other embodiments, process stage 172is omitted from process flow 160, and process stage 174 merelyrepresents the output of process stage 166. The final determination madeat process stage 174, along with the first applicant search history data170 (and any other data) used to make that determination, may be fedback into process stage 164 to provide additional labeled data forpurposes of updating the rules. In some embodiments, a preliminary frauddetermination made at process stage 166 is also fed back into processstage 164, to allow the machine learning program to determine andimprove upon past performance/accuracy.

E. Exemplary Process Flow for Machine Learning of Fraud DisputeResolution Rules

Referring now to FIG. 3E, an exemplary process flow 180 may generally beused to facilitate the resolution of fraud disputes (or potentialdisputes) with customers/account holders. For example, the process flow180 may be used to determine whether a reportedly unauthorized orfraudulent transaction (e.g., one that the account holder reported assuch when looking at his or her account statement) was indeedunauthorized or fraudulent. In some embodiments, the process flow 180may also, or instead, be used to determine whether an “unrecognized”transaction (i.e., one that the account holder does not recall, but doesnot necessarily report as fraudulent) was unauthorized or fraudulent.

In the process flow 180, multi-account data 182 may represent dataassociated with financial accounts of a number (e.g., thousands) ofaccount holders. For example, the multi-account data 182 may includedata associated with financial transactions relating to credit cardaccounts, debit card accounts, savings accounts, checking accounts, etc.For ease of explanation, FIG. 3E will be described with reference to anembodiment in which the accounts are credit card accounts.

In one embodiment, the multi-account data 182 may include transactiondata (e.g., transaction dates, amounts, locations, etc.) obtained fromFAMS 14 (e.g., by external data collection unit 42 of FIG. 1). In someembodiments, however, the multi-account data 182 also includesinformation obtained from cardholder computing devices 20, merchantcomputing systems 22, and/or other sources 24. For example, themulti-account data 182 may include, in addition to transaction data fromaccount records database 30 of FAMS 14, data indicative of IP addressesof cardholder computing devices 20 and/or devices in merchant computingsystems 22, Internet browsing and/or search history data from cardholdercomputing devices 20 (or from an ISP computer system included in othersources 24, etc.), vehicle telematics data from telematics systems ofcardholder vehicles, home occupancy and/or usage data (e.g., smartappliance data) from smart home systems of cardholders, autonomousvehicle data, smart vehicle data, mobile device data, vehicle or mobiledevice GPS data, and/or one or more other types of data. Some or alldata within multi-account data 182 may be information that accountholders or potential account holders have expressly consented to sharewith an entity associated with FAMS 14 and/or AFSS 12 (e.g., in exchangefor fraud protection services).

As described above in connection with multi-account data 82 of processflow 80, the multi-account data 182 may be associated with multiplefraud determination labels (e.g., “fraud” and “no fraud,” and/or morecomplex labels that indicate type/class, such as “lost/stolen card use,”etc.). In some embodiments, each label may be associated with a data setthat includes the corresponding portion of multi-account data 182. Thelabels may include final fraud determinations that were made via earlieriterations of the process flow 180, and/or external to the process flow180. Multi-account data 182 may include many (e.g., thousands) ofpositively and negatively labeled data sets.

At a process stage 184, the multi-account data 182 may be analyzed togenerate query generation rules (e.g., to be stored in ML rules database58). As described above in connection with process stage 84 of processflow 80, any suitable type of supervised machine learningprogram/technique(s) may be used. Generally, process stage 184 may serveto identify which types of information are probative of whether fraudhas occurred, and to craft rules that formulate queries to ascertainsuch information based upon account data.

For example, process stage 184 may determine that, for a suspect “cardpresent” transaction, a verified, non-fraudulent “card present”transaction within 10 miles and 3 hours of the suspect transaction isprobative of whether the suspect transaction was fraudulent. Based uponthis finding, process stage 184 may also generate a rule specifying thata cardholder should be queried as to whether he/she can confirm makingeach “card present” transaction within 10 miles and 3 hours of thesuspect transaction. As another example, process stage 184 may determinethat a merchant using a billing alias different from its legal and/orcommonly-known name (e.g., by at least some threshold level ofsimilarity, as measured by number of similar characters, order ofcharacters, etc.) is probative of whether the cardholder authorized atransaction associated with that billing alias. Based upon this finding,process stage 184 may generate a rule specifying that a cardholdershould be queried as to whether he/she is aware of a billing alias usedfor a suspect transaction if that billing alias is sufficientlydifferent from the legal/common name of the merchant.

At process stage 186, the rules generated or updated at process stage184 may be applied to first account data 190. The first account data 190may be associated with a particular cardholder, such as a cardholderassociated with a particular one of cardholder computing devices 20, forexample. The types of data included in first account data 190 may dependupon which types of data were determined, by process stage 184, to berelevant to developing dispute resolution queries. Process stage 186 maygenerate a set of one or more queries in accordance with the rules andthe contents of first account data. Some specific examples of rules thatmay be generated by process stage 184 and applied at process stage 186,and the queries that may be generated as a result, are described belowin connection with FIG. 4E.

At a process stage 192, the generated queries may be sent to thecardholder in one or more of various ways, such as sending the queriesvia SMS text message and/or email, and/or via a web browser or dedicatedapplication executing on the one of cardholder computing devices 20 thatis associated with the cardholder, for example. At a process stage 194,responses to the queries are received from the cardholder (e.g., viainputs made by the cardholder via the web browser or application, or aresponsive SMS text message or email, etc.). In some embodiments, therules generated or updated at process stage 184 specify the manner inwhich follow-up queries should be generated based upon the responsesreceived at process stage 194, and process stages 192 and 194 may berepeated multiple times.

In some embodiments, further analysis (e.g., a manual review, or furtherautomated review using additional data sources, etc.) that makes use ofthe received responses is performed at an additional stage, shown indashed lines in FIG. 3E as process stage 196. The additional analysismay then be used to make a final fraud determination (e.g., a finaldecision on whether fraud occurred, and/or on the type of fraud thatoccurred) at process stage 198. In other embodiments, process stage 196is omitted from process flow 180, and process stage 198 is based uponinformation from the cardholder. For example, the questions generated atprocess stage 192 may “jog” the cardholder's memory, and cause him orher to indicate that the transaction at issue was authorized. The finaldetermination made at process stage 198, along with the first accountdata 110 (and any other data used at process stage 196), the queriesgenerated at process stage 186 and/or the responses received at processstage 194, may be fed back into process stage 184 to provide additionallabeled data for purposes of updating the rules.

F. Exemplary Process Flow for Machine Learning of Document FraudDetection Rules

Referring now to FIG. 3F, an exemplary process flow 200 may generally beused to detect fraud relating to documents, such as counterfeit and/orforged documents. The process flow 200 may be used in connection withvarious kinds of documents, such as checks (e.g., personal checks,cashier's checks, etc.), money orders, treasury bills, identificationdocuments (e.g., social security cards, driver's licenses, passports,birth certificates, etc.), certification documents, and so on.

In the process flow 200, multi-document image data 202 may representdigital images of a number (e.g., thousands) of physical documents ofone or more types. The multi-document image data 202 may include imagesin one or more formats, such as raster formats (e.g., JPEG, TIFF, GIF,BMP, PNG, etc.) and/or vector formats (e.g., CGM, SVG, etc.), forexample. The multi-document image data 202 may include data obtained(e.g., by external data collection unit 42 of FIG. 1) from merchantcomputing systems 22 (e.g., point-of-sale devices with cameras fordocument identification) and/or from FAMS 14 (e.g., images of personalchecks), for example. In some embodiments, the multi-document image data202 may only include data representing images that customers (or otherindividuals associated with the documents) have expressly consented toshare (e.g., as a prerequisite to making a purchase, or in exchange forfraud protection services, etc.).

As described above in connection with multi-account data 82 of processflow 80, the multi-document image data 202 may be associated withmultiple fraud determination labels. In some embodiments, each label maybe associated with data representing a digital image of a particulardocument. The labels may include final fraud determinations (e.g.,“fraud” or “no fraud,” or more complex labels such as “forgery,”“counterfeit,” “forgery-signature,” “counterfeit-angular line offset(s)outside tolerance,” etc.) that were made via earlier iterations of theprocess flow 200, and/or external to the process flow 200.Multi-document image data 202 may include many (e.g., thousands) ofpositively and negatively labeled data sets.

At a process stage 204, the multi-document image data 202 may beanalyzed to generate document fraud detection rules (e.g., to be storedin ML rules database 58). As described above in connection with processstage 84 of process flow 80, any suitable type of supervised machinelearning program/technique(s) may be used. Generally, process stage 204may serve to identify which characteristics of a document are probativeof whether the document is counterfeit, and to determine the ranges,tolerances, etc., that are probative of whether the document iscounterfeit. In some embodiments, process stage 204 also, or instead,identifies which characteristics of information entered in documentfields are probative of whether the document was forged (e.g., draftedor populated by someone other than the person purported to have draftedor populated the document).

At process stage 206, the rules generated or updated at process stage204 may be applied to first document image data 210. The first documentimage data 210 may be digital image data corresponding to a particular,physical document. The first document image data 210 may includeinformation obtained (e.g., by external data collection unit 42) fromone of merchant computing systems 22 (e.g., for real-time verificationof an identification or other document presented during or prior to asale), or from FAMS 14 (e.g., for real-time or batch-processingverification of a personal check prior to clearing the check), forexample. Some specific examples of rules that may be generated byprocess stage 204, and applied at process stage 206, are described belowin connection with FIG. 4F.

Process stage 206 may output information indicating whether fraud issuspected in connection with the document corresponding to firstdocument image data 210. For example, process stage 206 may output twopercentage probabilities calculated according to the rules generated orupdated at process stage 204, with the first indicating the likelihoodthat the document is counterfeit and the second indicating thelikelihood that the document includes forged content. As anotherexample, process stage 206 may output binary indicators of whether thedocument likely is, or likely is not, counterfeit and/or includes forgedcontent (e.g., by comparing percentage probabilities to thresholdprobabilities).

In some embodiments, further analysis (e.g., a manual review, or furtherautomated review using additional data sources, etc.) may be performedat a process stage 212. The additional analysis may then be used to makea final fraud determination (e.g., a final decision on whether thedocument is fraudulent) at process stage 214. For example, the processstage 206 may act as a filter, and flag only those documents having arelatively high probability of being fraudulent. In this manner, aconsiderably smaller amount of human and/or processing resources may beconsumed at process stage 212.

The final determination made at process stage 214, along with the firstdocument image data 210 used to make that determination, may be fed backinto process stage 204 to provide additional labeled data for purposesof updating the rules. In some embodiments, a preliminary frauddetermination made at process stage 206 may also be fed back intoprocess stage 204, to allow the machine learning program to determineand improve upon past performance/accuracy.

IV. Exemplary Rules for Fraud Detection and/or Classification

FIGS. 4A-4F depict exemplary factors and algorithms that may be used inconnection with various fraud detection and/or classification rules,according to different embodiments. It is noted that the rule setscorresponding to FIGS. 4A-4F are purely for purposes of illustration andare not limiting. Particularly in embodiments where machine learning isutilized, for example, the algorithms and/or factors may be far morecomplex, and/or less intuitive, than some or all of the examples shownin FIGS. 4A-4F.

A. Exemplary Fraud Detection Rule Set Using Online Activity

Referring first to FIG. 4A, an exemplary rule set 220 (e.g., generatedat process stage 104 of FIG. 3A) may use various factors relating toonline activity of a cardholder to detect fraud in connection with aparticular credit or debit card transaction. The rule set 220 maycorrespond to a particular embodiment and scenario in which thetransaction at issue is a “card present” transaction, and in which therule set 220 seeks to determine whether the cardholder made or otherwiseauthorized the transaction. The rule set 220 may be incorporated into areview process that is generally applied to all transactions, a reviewprocess applied only to those transactions that were flagged by apreliminary fraud alert, or a review process applied only after acardholder reports the transaction as unauthorized, for example.

The factors considered under the rule set 220 may include a number ofinterest-based factors 222 and a number of location-based factors 224.The interest-based factors 222 may relate to the cardholder's interest(or non-interest) in a product or service purchased via the transaction,and/or the merchant providing the product or service, while thelocation-based factors 224 may relate to the cardholder's location orprobable location.

As seen in FIG. 4A, the interest-based factors 222 may include: (1)whether the cardholder searched online for the specific product orservice purchased via the transaction at issue (e.g., by determiningwhether search terms entered by the cardholder included the name of theproduct or service involved in the transaction, or included adescription of the product or service, etc.); (2) whether the cardholdervisited a website associated with the merchant (e.g., by comparing URLsof web sites visited by the cardholder to a known URL of the merchant'swebsite, or by searching the contents of websites visited by thecardholder for the merchant's name, etc.); (3) whether the cardholderendorsed the merchant, or the product or service provided by themerchant, via a social media account of the cardholder (e.g., bydetermining whether the cardholder “liked” the merchant, product orservice via his or her Facebook® account, etc.); (4) whether thecardholder visited a website associated with a competitor of themerchant (e.g., by comparing URLs of web sites visited by the cardholderto known URLs of known competitors' websites, or by searching thecontents of websites visited by the cardholder for the competitors'names, etc.); (5) whether the cardholder searched online for a differentproduct or service in the same price range as the transaction amount(e.g., by analyzing search terms and/or results, and/or by analyzingURLs or contents of websites visited by the cardholder and comparingprices of products/services, etc.); and/or (6) whether the cardholderentered search terms indicative of the cardholder's need for the productor service (e.g., by determining that the cardholder entered searchterms including “pipe leak” prior to the purchase of new plumbinghardware, or “computer repair” prior to the purchase of a new harddrive, etc.). In other embodiments, the interest-based factors 222 mayinclude more, fewer and/or different factors than those shown in FIG.4A.

As is also seen in FIG. 4A, the location-based factors 224 may include:(1) whether the cardholder “checked in” to a flight having a destinationnear the location where the transaction was initiated (e.g., bydetermining whether the cardholder checked in to a flight having adestination at the city in which the transaction occurred, or within athreshold number of miles of the city in which the transaction occurred,etc.); (2) whether the cardholder visited a website associated with aplace near (or in) which the transaction was initiated (e.g., bycomparing URLs of web sites visited by the cardholder to URLs ofwebsites known to be associated with particular areas, and/or bysearching the contents of websites visited by the cardholder forlocation or area names, etc.); and/or (3) whether the cardholderendorsed a place near (or in) which the transaction was initiated via asocial media account of the cardholder (e.g., by determining whether thecardholder “liked” the geographic area, attraction or other place viahis or her Facebook® account, etc.). In other embodiments, thelocation-based factors 224 may include more, fewer and/or differentfactors than those shown in FIG. 4A.

Generally, the data indicative of whether the circumstance correspondingto each of interest-based factors 222 and/or location-based factors 224is present/true for a particular cardholder may be included in the firstcustomer online activity data 110 described above in connection withFIG. 3A. For example, external data collection unit 42 of FIG. 1 mayobtain the search terms, URLs, user online selections, etc., needed todetermine whether the various factors exist, from the cardholder'scomputing device (e.g., one of cardholder computing devices 20) and/orfrom an ISP of other sources 24.

As is also seen in FIG. 4A, each of the interest-based factors 222 andlocation-based factors 224 may be associated with a particular score orweighting value. In the rule set 220 shown in FIG. 4A, a total score maybe calculated based upon which factors are, or are not, present (e.g.,add 94 points if it is determined that the cardholder searched for theparticular lawnmower model that was purchased, add another 80 points ifthe transaction was a “card present” transaction in the Chicago suburbof Joliet and the cardholder checked in to a flight to Chicago justprior to the transaction, etc.).

In some embodiments, certain factors may instead be associated withnegative scores (e.g., minus 80 if the cardholder checked in to a flightwith a destination at least 200 miles from the site of the transactionand within one day of the transaction, etc.). Moreover, certain factorsmay be associated with metrics or algorithms that determine how heavilythose factors are weighed. As indicated in FIG. 4A, for example, searchterms entered by the cardholder may be used to calculate a “need score”X (e.g., where X is based upon frequency of certain search terms beingused, the amount of time spent clicking through search results, themagnitude and/or urgency of a problem indicated by the search terms,etc.), with X then being used to calculate a score equal to 0.2X.

The rule set 220 may then output the total score (e.g., 94+80=+174), anormalized total score, an indication of whether the total scoreexceeded a threshold (e.g., a threshold of +100), a probabilitycalculated based upon the total score, and/or some other indicator ormeasure of the existence or likelihood of fraud. In the example shown inFIG. 4A, it can be seen that larger scores generally correspond to agreater probability that the transaction was made or authorized by thecardholder. If the transaction is being automatically reviewed (e.g., todetermine whether a fraud alert is appropriate, without any initialinput from the cardholder), this may mean that a lower score correspondsto a higher probability of fraud. Conversely, if the cardholder hadreported the transaction as being fraudulent, a higher score maycorrespond to a higher probability of fraud (i.e., fraud on the part ofthe cardholder).

In some embodiments, the rule set 220 may also include one or more othertypes of factors not necessarily based upon online activities of thecardholder (e.g., whether GPS of the cardholder's smartphone or vehicleindicates that he or she was in that area shortly before or after thetransaction, etc.), and/or may omit either interest-based factors 222 orlocation-based factors 224.

B. Exemplary Chargeback Candidate Detection Rule Set

Referring next to FIG. 4B, an exemplary rule set 230 (e.g., generated atprocess stage 124 of FIG. 3B) may use various factors relating to atransaction between a cardholder and a merchant to determine whether thetransaction should be flagged as a candidate for a chargeback (e.g., todetermine whether the transaction should be reviewed under a full set ofchargeback rules associated with the appropriate card network entity).The rule set 230 may correspond to a particular embodiment and scenarioin which the transaction at issue is a “card present” transaction.

As seen in FIG. 4B, the factors considered under the rule set 230 mayinclude: (1) whether an EMV chip card was not inserted in apoint-of-sale EMV chip reader device of the merchant; (2) whether anon-EMV card was not swiped in a point-of-sale device of the merchant;(3) whether the card is past its expiration date; (4) whether thetransaction is for the same amount and/or date as another transactioninvolving the same card and merchant (e.g., by analyzing othertransactions involving the same account and merchant within a particulartime span); and/or (2) whether the transaction is for greater than athreshold amount. For example, one of merchant computing systems 22 ofFIG. 1 (or an acquiring/merchant bank) may provide transaction detailsthat include the amounts, dates, etc., to FAMS 14 for storage in accountrecords database 30, and external data collection unit 42 may thenretrieve that information from account records database 30. Generally,the data indicative of whether the circumstance corresponding to each ofthe factors is present/true for a particular transaction may be includedin the first account transaction data 130 described above in connectionwith FIG. 3B. In other embodiments, the factors considered under ruleset 230 may include more, fewer and/or different factors than thoseshown in FIG. 4B. It is noted that, in some embodiments, one or morefactors may simply relate to the desirability (e.g., from a card issuerperspective) of further reviewing whether a chargeback is appropriate,without necessarily relating to the likelihood that a chargeback isappropriate.

As is also seen in FIG. 4B, each of the factors may be associated with aparticular score or weighting value. A total score may be calculatedbased upon which factors are, or are not, present (e.g., add 62 pointsif it is determined that the transaction has the same amount and date asanother transaction occurring close in time and involving the same cardand merchant). In some embodiments, certain factors may instead beassociated with negative scores, and/or certain factors may beassociated with metrics or algorithms that determine how heavily thosefactors are weighed.

The rule set 230 may then output the total score, a normalized totalscore, an indication of whether the total score exceeded a threshold, aprobability calculated based upon the total score, and/or some otherindicator or measure of the likelihood that a chargeback is appropriatefor the transaction. In the example shown in FIG. 4B, it can be seenthat larger scores generally correspond to a greater probability that achargeback is appropriate.

C. Exemplary Fraud Classification Rule Set

Referring now to FIG. 4C, an exemplary rule set 240 (e.g., generated atprocess stage 144 of FIG. 3C) may use a diverse array of factors toclassify the type(s) of fraudulent activity, if any, that is/aresuspected to be associated with an event or series of events. The ruleset 240 may correspond to a particular embodiment and scenario in whichthe event at issue is a financial transaction involving a debit orcredit card. In other embodiments and/or scenarios, however, the ruleset 240 may classify fraudulent activity with respect to specific othertypes of events (e.g., loan applications), or may detect a variety ofdifferent event types (e.g., various types of financial transactions,loan or credit applications, etc.) and broadly classify fraudulentactivity in connection with the detected event types (e.g., lost/stolencard use, application fraud, etc.).

In one embodiment, each potential classification (with the possibleexception of “no fraud”) may be associated with a number of factorsprobative of whether that type/class of fraud has occurred. As seen inFIG. 4C, for example, the rule set 240 may include counterfeit factors242 (e.g., factors indicating that a counterfeit card was used for thetransaction), account takeover factors 244 (e.g., factors indicatingthat the transaction resulted from an unauthorized person gaining onlineaccess to the credit or debit card account itself, via phishing, malwareor other means), chargeback fraud factors 246 (e.g., factors indicatingthat the cardholder made or otherwise authorized a purchase that thecardholder later contested) and skimming factors 248 (e.g., factorsindicating that the card information used for the transaction wasobtained via a skimming card reader device illegally installed in anATM, gas station pump or other location). In other embodiments, the ruleset 240 may also, or instead, include factors corresponding to one ormore other fraud classifications (e.g., forgery, lost/stolen card use,etc.).

As seen in FIG. 4C, the counterfeit factors 242 may include: (1) whetherthe suspect transaction and another, contemporaneous transaction (e.g.,occurring within one hour, etc.) in another state are both “cardpresent” transactions; and/or (2) if the suspect transaction is a “cardpresent” transaction, whether the card (if an EMV chip card) was notinserted in an EMV chip card reader. For example, one or more ofmerchant computing systems 22 of FIG. 1 (or one or moreacquiring/merchant banks) may provide transaction details that includewhether the transaction was “card present,” whether the card wasinserted in an EMV chip card reader, etc., to FAMS 14 for storage inaccount records database 30, and external data collection unit 42 maythen retrieve that information from account records database 30. Inother embodiments, the counterfeit factors 242 may include more, fewerand/or different factors than those shown in FIG. 4C.

The account takeover factors 244 may include: (1) whether the debit orcredit card account password was changed within the 10 days prior to thetransaction; and/or (2) whether the transaction was originated from anIP address not associated with the cardholder. For example, externaldata collection unit 42 may retrieve password change information fromaccount records database 30 of FIG. 1, which may log all password updateactivity, and/or may retrieve IP address information from one ofmerchant computing systems 22 (e.g., the computing system of themerchant involved in the transaction). In other embodiments, the accounttakeover factors 244 may include more, fewer and/or different factorsthan those shown in FIG. 4C.

The chargeback fraud factors 246 may include: (1) whether the cardholderhad searched online for the product or service purchased via thetransaction; and/or (2) whether the cardholder had visited a websiteassociated with the merchant involved in the transaction. For example,external data collection unit 42 of FIG. 1 may retrieve online searchinformation (e.g., search terms and/or results) and/or URLs from the oneof cardholder computing devices 20 that is associated with thecardholder, and/or from an ISP (of other sources 24) used by thecardholder. In other embodiments, the chargeback fraud factors 246 mayinclude more, fewer and/or different factors than those shown in FIG.4C.

The skimming factors 248 may include: (1) the number (X) of earliertransactions in which the card used for the transaction at issue wasused at an ATM machine or a gas station pump within the 10 days prior tothe transaction at issue; and/or (2) whether the transaction at issueoriginated from an IP address not associated with the cardholder. Forexample, external data collection unit 42 of FIG. 1 may retrievetransaction data indicating that certain past purchases were made usinggas station pump card readers, and/or indicating that the card was usedfor one or more ATM withdrawals, from account records database 30,and/or may retrieve the originating IP address from the one of merchantcomputing systems 22 associated with the merchant involved in thetransaction at issue. In other embodiments, the skimming factors 248 mayinclude more, fewer and/or different factors than those shown in FIG.4C.

Generally, the data indicative of whether the circumstance correspondingto each of counterfeit factors 242, account takeover factors 244,chargeback fraud factors 246 and/or skimming factors 248 is present/truefor a particular transaction may be included in the first account data150 described above in connection with FIG. 3C, for example.

As is also seen in FIG. 4C, each of the counterfeit factors 242, accounttakeover factors 244, chargeback fraud factors 246 and skimming factors248 may be associated with a particular score or weighting value. Thefactors for each classification (counterfeit, account takeover,chargeback fraud, skimming) may be used to calculate a total scorespecific to that classification. In the rule set 240 shown in FIG. 4C,for example, a counterfeit score may be calculated based upon which offactors 242 are, or are not, present, an account takeover score may becalculated based upon which of factors 244 are, or are not, present, andso on. In some embodiments, certain factors may instead be associatedwith negative scores, and/or certain factors (e.g., the first ofskimming factors 248 shown in FIG. 4C) may be associated with metrics oralgorithms that determine how heavily those factors are weighed.

For each classification/category, the rule set 240 may output the totalscore, a normalized total score, an indication of whether the totalscore exceeded a threshold, a probability calculated based upon thetotal score, and/or some other indicator or measure of the likelihoodthat fraud of that particular type/class occurred in connection with thetransaction. In the example shown in FIG. 4C, it can be seen that largerscores generally correspond to a greater probability that the respectiveclassification is accurate. Referring back to FIG. 3C, theclassification at process stage 152 may be the classification having thehighest score and/or probability under rule set 240, or may include thescore and/or probability for each classification, the top threeclassifications, etc.

D. Exemplary Application Fraud Detection Rule Set

Referring now to FIG. 4D, an exemplary rule set 260 may use onlinesearch information (e.g., search terms, search results, clicked/selectedsearch results, etc.) to detect whether an application was fraudulent(e.g., not populated and/or submitted by the purported applicant). Therule set 260 may have been generated at process stage 164 of FIG. 3D,for example. The rule set 260 may be incorporated into a review processthat is generally applied to all applications received by a particularentity or anti-fraud service, or a review process applied only to thoseapplications that were flagged by a preliminary fraud alert, forexample.

The factors considered under the rule set 260 may generally be probativeof whether the person that submitted the application (e.g., via a webbrowser, a dedicated application, as an email attachment, by snail mail,etc.) had performed one or more online searches indicating that he orshe was trying to learn more about the purported applicant in order topopulate particular fields of the application (e.g., a “home address”field, “employment history” fields, etc.). The “purported applicant” maybe a person whose name appears in a name and/or signature field of theapplication, for example.

As seen in FIG. 4D, the factors of exemplary rule set 260 may include:(1) whether the applicant used search terms that included the name ofthe purported applicant; (2) whether the search terms also included thewords “address” or “residence” (and possibly other synonyms ornear-synonyms); and/or (3) whether the search terms also included thewords “employer,” “job” and/or “career” (and possibly other synonyms ornear-synonyms). In other embodiments, the rule set 260 may include more,fewer and/or different factors than those shown in FIG. 4D. For example,the rule set 260 may include one or more factors relating to whichsearch results appeared and/or were selected (e.g., “clicked” on afterappearing on a user interface) by the applicant.

Generally, the data indicative of whether the circumstancescorresponding to the factors of rule set 260 are present/true for aparticular applicant may be included in the first applicant searchhistory data 170 described above in connection with FIG. 3D. Forexample, external data collection unit 42 of FIG. 1 may obtain thesearch terms, search results, search result user selections, etc.,needed to determine whether the various factors exist, from theapplicant's computing device (e.g., similar to one of cardholdercomputing devices 20) and/or from an ISP of other sources 24. Access tosuch information may be made a condition of having the application beconsidered, for example.

As is also seen in FIG. 4D, each of the factors of rule set 260 may beassociated with a particular score or weighting value. A total score maythen be calculated based upon which factors are, or are not, present. Insome embodiments, certain factors may instead be associated withnegative scores, and/or certain factors may be associated with metricsor algorithms that determine how heavily those factors are weighed.

The rule set 260 may then output the total score, a normalized totalscore, an indication of whether the total score exceeded a threshold, aprobability calculated based upon the total score, and/or some otherindicator or measure of the existence or likelihood of applicationfraud. In the example shown in FIG. 4D, it can be seen that largerscores may generally correspond to a greater probability that theapplication was not populated and/or submitted by the purportedapplicant.

E. Exemplary Fraud Dispute Resolution Rule Set

Referring now to FIG. 4E, a flow diagram illustrates at least a portionof a process flow 270 implementing an exemplary rule set for frauddispute, or potential fraud dispute, resolution (e.g., a rule setgenerated at process stage 184 of FIG. 3E). The process flow 270 may beused to help resolve a dispute over a contested transaction, or to helpa customer recall an unrecognized transaction, for example. FIG. 4Eillustrates a process flow, rather than just a set of factors, in orderto better illustrate an example process for generating queries basedupon the generated rules, according to one embodiment. The process flow270 may correspond to a particular embodiment and scenario in which thetransaction subject to dispute or potential dispute is a credit or debitcard transaction.

In the exemplary process flow 270, the rule set may specify that aprocess stage 272 determines whether the transaction was a “cardpresent” transaction. If not, the rule set may specify that the flowproceed directly to a process stage 280. If so, however, the rule setmay specify that the flow instead proceeds to a process stage 274.

The rule set may also specify that process stage 274 determines whetherat least one other transaction associated with the cardholder's accountoccurred within some threshold number of hours (X) of the transaction atissue. If not, the rule set may specify that the flow proceeds directlyto process stage 280. If so, however, the rule set may specify that theflow instead proceeds to a process stage 276.

Process stage 276 may generate one or more location-related queriesusing transaction data associated with the cardholder's account. Thequeries may ask, for example, whether the cardholder was in (or near)one or more particular geographic areas or locations at various times.If the transaction at issue occurred in San Francisco, for example, witha first other “card present” transaction occurring in Santa Rosa fourhours earlier and a second other “card present” transaction occurring inSan Jose two hours later, process stage 276 may generate one or morequeries asking whether the cardholder made or authorized the earlierand/or later transactions, and/or whether the cardholder traveled on aroute from Santa Rosa to San Jose that passed through San Francisco,etc.

In some embodiments, the location-related queries are generated basedupon data associated with events or circumstances other thantransactions. For example, if the transaction at issue occurred inSarasota, Fla., and the data considered under the rule set indicatesthat the cardholder checked in to a flight to Tampa, process stage 276may generate one or more queries asking whether the cardholder completedthe flight, where the cardholder went after landing in Tampa, etc.

The rule set may also specify that process stage 280 determines whetherthe transaction at issue is associated with a billing alias that isdissimilar to the name of the merchant involved in the transaction. Forexample, the computing system of the merchant (e.g., one of merchantcomputing systems 22 of FIG. 1) may have sent to FAMS 14 a transactionrecord that identified the merchant by the alias, and was presented tothe cardholder as an online or paper account statement. Thedetermination at process stage 280 may use the billing alias to identifya legal and/or common name of the merchant (e.g., using a relationaldatabase stored in AFSS 12 or FAMS 14), and determine that there is atleast some threshold level of dissimilarity (e.g., based upon differenceof characters, character ordering, etc.) between the billing alias andthe merchant name.

If the billing alias and merchant name are not sufficiently dissimilar,the rule set may specify that the flow proceeds directly to a processstage 284. If sufficiently dissimilar, however, the rule set may specifythat the flow instead proceeds to a process stage 282. Process stage 282may generate a query relating to the billing alias that was presented tothe cardholder. For example, the query may ask whether the cardholder isaware that the billing alias is used by that particular merchant. Insome embodiments, process stage 282 may instead generate a message thatsimply informs the cardholder that the billing alias corresponds to themerchant, without posing a question.

The rule set may specify that process stage 284 generates one or moredefault queries. For example, one default query may ask whether thecardholder lent his or her card to a friend or family member around thetime of the transaction. In some embodiments and/or scenarios, processstage 284 may be omitted from process flow 270. Generally, the queries(and possibly non-query messages) generated in process flow 270 mayserve to help the cardholder recall whether the transaction was made orauthorized, and/or process flow 270 may prompt the cardholder forresponses that are considered by others (e.g., personnel of an entityassociated with FAMS 14 of FIG. 1) to determine whether the transactionwas likely fraudulent.

Although not shown in FIG. 4E, in some embodiments process flow 270 mayinclude a number of iterative stages in which responses are receivedfrom the cardholder (e.g., from the respective one of cardholdercomputing devices 20 in FIG. 1) and used to generate additional, moredetailed questions for the cardholder. For example, if a first queryasks whether the cardholder recalls personally making another “cardpresent” transaction that occurred at a nearby time and place, and thecardholder responds “no,” a new query may be generated asking whetherthe cardholder recalls personally making the next closest transaction(in terms of time and/or location).

F. Exemplary Document Fraud Detection Rule Set

Referring next to FIG. 4F, an exemplary rule set 290 (e.g., generated atprocess stage 204 of FIG. 3F) may use various factors relating to animaged (e.g., photographed or scanned) physical document to determinewhether the document should be flagged as a candidate for a morein-depth (e.g., manual) analysis/review for fraud purposes. The rule set290 may correspond to a particular embodiment and scenario in which thedocument is one that includes at least a signature field (e.g., apersonal check, a driver's license, etc.).

The factors considered under the rule set 290 may include a number ofcounterfeit factors 292 and a number of forgery factors 294, each ofwhich may be evaluated by image analysis unit 52 of FIG. 1 using one ormore image processing techniques. The counterfeit factors 292 may relateto the look, presentation, format and/or structure of the document,while the forgery factors 294 may relate to the substance, style orformat of information entered in one or more fields of the document.

As seen in FIG. 4F, the counterfeit factors 292 may include: (1) whetherone or more absolute or relative dimensions and/or angles of thedocument, or of lines, illustrations, patterns, etc. shown on thedocument (excluding user-entered contents in fields such as thesignature line), are outside one or more predetermined tolerances; (2)whether one or more colors on the document are outside a predeterminedtolerance (e.g., color/frequency range); (3) whether one or more linethicknesses of the document (excluding user-entered field contents) areoutside one or more predetermined tolerances; and/or (4) whether one ormore fonts on the document (excluding user-entered field contents) areoutside one or more predetermined tolerances. For example, imageanalysis unit 52 may determine whether the ratio of the document lengthto the document width is within 0.1% of an expected value. As anotherexample, image analysis unit 52 may determine whether horizontal andvertical lines on the document are within 0.3 degrees of the horizontaland vertical edges of the document, respectively. As yet anotherexample, image analysis unit 52 may determine whether a font used for afield descriptor or other text on the document matches an expected font(e.g., by meeting a similarity threshold measured in any suitablemanner). In other embodiments, the counterfeit factors 292 may includemore, fewer and/or different factors than those shown in FIG. 4F.

The forgery factors 294 may include: (1) whether a signature entered ina signature field of the document match is outside a predeterminedtolerance (e.g., using any suitable signature recognition technique);(2) whether handwriting entered in one or more fields of the document isoutside a predetermined tolerance (e.g., by applying a suitablehandwriting recognition technique); and/or (3) whether the format ofinformation entered by a user in one or more fields does not match anexpected format (e.g., using “9.12.16” rather than the expected“9/12/2016,” as established based upon other documents known to havebeen populated and/or submitted by the purported applicant). In otherembodiments, the forgery factors 294 may include more, fewer and/ordifferent factors than those shown in FIG. 4F.

Generally, the data indicative of whether the circumstancescorresponding to counterfeit factors 292 and/or forgery factors 294 arepresent/true for a particular document may be included in the firstdocument image data 210 described above in connection with FIG. 3F.

As is also seen in FIG. 4F, each of the counterfeit factors 292 andforgery factors 294 may be associated with a particular score orweighting value. In the rule set 290 shown in FIG. 4F, a total score maybe calculated based upon which factors are, or are not, present. In someembodiments, certain factors may instead be associated with negativescores, and/or certain factors may be associated with metrics oralgorithms that determine how heavily those factors are weighed.

The rule set 290 may then output the total score, a normalized totalscore, an indication of whether the total score exceeded a threshold, aprobability calculated based upon the total score, and/or some otherindicator or measure of the likelihood that the document is fraudulent.Alternatively, the rule set 290 may output a separate total score,normalized score, probability, or other metric, for each of counterfeitfactors 292 and forgery factors 294, with the counterfeit metricindicating the likelihood that the document is a counterfeit and theforgery metric indicating the likelihood that the document wasfraudulently populated by someone other than the purported person (e.g.,by someone other than the person corresponding to the name, signature,address, etc. on the document). In the example shown in FIG. 4F, it canbe seen that larger scores generally correspond to a greater probabilitythat the document is fraudulent. In some embodiments, the rule set 290also includes one or more other types of factors not shown in FIG. 4F,and/or omits either counterfeit factors 292 or forgery factors 294.

V. Exemplary Methods for Fraud Detection & Classification

FIGS. 5-7 depict flow diagrams of various exemplary computer-implementedmethods that may be implemented by one or more components of AFSS 12 ofFIG. 1. In one embodiment, AFSS 12 implements all of the methodscorresponding to FIGS. 5-7. In other embodiments, AFSS 12 implementsonly a subset (e.g., one, two, etc.) of the methods corresponding toFIGS. 5-7. Each of the methods described below may be implemented byfraud detection/classification unit 36 of FIG. 1, for example.

A. Exemplary Methods for Facilitating Fraud Dispute Resolution

Referring first to FIG. 5, an exemplary computer-implemented method 300may be used to facilitate a fraud dispute resolution process involving acustomer associated with a financial account. In the method 300, typesof information historically indicative of fraud (or an absence of fraud)may be identified (block 302). The information types may be identifiedat least in part by training a machine learning program, such as any ofthe types of machine learning programs discussed above in connectionwith ML rule generator 40 of FIG. 1 or process stage 84 of FIG. 2, forexample. The machine learning program may be trained using transactiondata associated with a plurality of financial transactions, and frauddeterminations/labels each corresponding to a respective one of theplurality of financial transactions.

An indication that fraud is suspected for a particular financialtransaction, associated with a particular financial account, may bereceived (block 304). For example, an automated investigation (e.g.,using any suitable process, method or technique described herein),and/or a manual investigation, may have been performed to determine thatthe financial transaction was potentially fraudulent in some way, and auser input or other data indicative of that outcome may be received atblock 304.

Transaction data, associated with the financial transaction, may beretrieved (block 306). For example, a database containing accountrecords (e.g., account records database 30 of FIG. 1) may contain a listof transactions associated with multiple accounts, and the transactionof interest may be retrieved at block 306 by accessing the informationstored in the database.

A first set of one or more queries may be generated (block 308) basedupon at least one of the types of information identified at block 302and the transaction data retrieved at block 306. The query or queriesmay be designed to ascertain whether the financial transaction wasindeed fraudulent. For example, one or more queries may be designed toascertain whether the customer was proximate to a location (e.g.,establishment, geographic area, etc.) where the financial transactionoccurred at the time the financial transaction occurred. As anotherexample, one or more queries may be designed to ascertain whether thecustomer recalls a different, second financial transaction associatedwith the financial account. As yet another example, one or more queriesmay be designed to ascertain whether the customer is aware of a billingalias associated with the financial transaction.

The first set of queries may be transmitted to a remote computing device(e.g., to one of cardholder computing devices 20 of FIG. 1) to cause theremote computing device to display the first set of queries to thecustomer (block 310). The remote computing device may display thequeries via a web browser, an email application, a text messageapplication, or a dedicated application, for example.

A first set of one or more customer responses may be received from theremote computing device (block 312). The response(s) may have beenentered by the customer using the same interface and/or application(e.g., email, text, web browser, etc.) via which the query or querieswas/were displayed, for example.

It may be determined, based upon the first set of customer responses,whether the financial transaction of interest was fraudulent (block314). In some embodiments and/or scenarios, the determination is notmade without one or more further iterations of queries and responses.For example, block 314 may include determining, based upon the customerresponses, a second set of one or more queries designed to ascertainwhether the financial transaction was fraudulent, transmitting thesecond set of queries to the remote computing device for display to thecustomer, receiving a second set of one or more customer responses fromthe remote computing device, and determining whether the financialtransaction was fraudulent based upon the second set of customerresponses.

In some embodiments, the method 300 may include one or more additionalblocks not shown in FIG. 5. For example, the method 300 may include ablock in which an indication of whether the financial transaction wasfraudulent (as determined at block 314) is caused to be displayed to oneor more people via one or more respective computing device userinterfaces. The indication may also specify the transaction at issue,the merchant, and possibly other information such as the transactiondate, dollar amount, etc. The indication may be sent to the remotecomputing device of the customer, for example, or to a computing deviceof a card issuer or other entity, etc. The indication may be generatedby notification unit 56 of FIG. 1, for example.

FIG. 6 illustrates a computer-implemented method 320 of fraud disputeresolution and/or reducing customer confusion caused by billing aliaseson credit card or other financial statements. The method 320 mayinclude, via one or more processors and/or transceivers (such as viawireless communication or data transmission over one or more radiofrequency links and/or wireless communication channels), (1) receivingan indication that a credit card financial transaction is being disputedby the card owner, and/or that the card owner does not recognize afinancial transaction, such as not recognizing a billing alias on acredit card or other financial activity statement (block 322); (2)determining or retrieving a billing merchant or billing alias associatedwith the disputed credit card transaction (and named on a credit cardstatement or other financial statement), such as via Optical CharacterRecognition (OCR) or Object Recognition (OR) techniques performed on thefinancial statement (block 324); (3) inputting the billing alias into amachine learning program trained to identify a real world orbrick-and-mortar merchant name associated with the billing alias (orotherwise determining a billing merchant associated with the disputedcredit card transaction) (block 326); and (4) generating andtransmitting an electronic notification indicating the real worldmerchant name to the customer's mobile device for customer review andverification to resolve or pre-empt any potential dispute (block 328).

The method 320 may further include, prior to transmission of anotification, (5) determining if the real world merchant has abrick-and-mortar location in the vicinity of the customer's home addresson file (block 330); and (6) if so, retrieving or accessing customermobile device or vehicle GPS (Global Positioning System) coordinatehistory (block 332). The method 320 may include (7) determining whetherthe card owner was at the GPS location of the real world merchant on theday of the transaction, such as by using the customer mobile device orvehicle GPS coordinate history (block 334); and (8) if so, generating anelectronic notification notifying the card owner (i) of the real worldmerchant's name or identification, (ii) location of the merchantassociated with the financial transaction, and/or (iii) that customerdata indicates that the customer was at the location of the merchant onthe day that financial transaction occurred (or that customer dataindicates that the financial transaction was correct or valid) (block336); and/or (8) transmitting the electronic notification to customermobile device for their review and/or verification (block 338) tofacilitate resolving or pre-empting erroneous disputes caused byunrecognized financial transactions or billing aliases.

In one embodiment, a computer-implemented method of pre-empting frauddisputes caused by billing alias or unrecognized merchant billing namesmay be provided. The method may include (1) receiving, via one or moreprocessors and/or transceivers, an indication that a credit cardfinancial transaction is unrecognizable by the card owner; (2)determining or retrieving, via the one or more processors, a billingalias for a merchant associated with the unrecognizable credit cardtransaction, the billing alias being named on a credit card statement asthe billing merchant; (3) determining, via the one or more processors, abrick and mortar name that the merchant associated with the billingalias is doing business as; (4) generating, via the one or moreprocessors, an electronic notification indicating the brick and mortarname of the merchant associated with the credit card financialtransaction; and/or (5) transmitting, via the one or more processorsand/or transceivers, the electronic notification indicating the brickand mortar name of the merchant to a mobile device of the customer viawireless communication or data transmission over one or more radio linksor wireless communication channels for customer review or approval tofacilitate preventing financial disputes caused by billing aliases oncredit card or other financial statements.

Determining, via the one or more processors, the brick and mortar namethat the merchant associated with the billing alias is doing business asmay be performed by inputting the billing alias into a machine learningprogram trained to determine a real world name for the merchant usingthe billing alias. Determining or retrieving, via the one or moreprocessors, a billing alias for a merchant associated with theunrecognizable credit card transaction may include applying an OCRtechnique onto a digital or hardcopy billing statement to retrieve ordetermine the billing alias, or retrieving the billing alias from adigital or virtual billing statement via processor analysis.

The method may also include, prior to transmission of the electronicnotification, determining, via the one or more processors, if the realworld merchant has a (GPS) location in a vicinity of the customer homeaddress; and if so, receiving, via the one or more processors and/ortransceivers, customer mobile device or vehicle GPS coordinate history.The method may also include (i) determining, via the one or moreprocessors, whether the card owner was at the (GPS) location of the realworld merchant on the day (and time) of the transaction based upon thecustomer mobile device or vehicle GPS coordinate history; (ii) if so,then generating, via the one or more processors, an electronicnotification notifying the card owner of the real world merchant's nameor identification, location of the merchant associated with thefinancial transaction, and/or that customer GPS data indicates that thecustomer was at the location of the merchant on the day (and/or time)that the financial transaction occurred; and/or (iii) transmitting, viathe one or more processors and/or transceivers, the electronicnotification to customer mobile device for their review and/orverification to facilitate resolving erroneous disputes caused byunrecognized financial transactions.

Additionally or alternatively, the method may include (i) comparing, viathe one or more processors, a GPS location of the real world merchantassociated with the transaction with a customer location at the time ofthe transaction to verify that the customer was at the merchant locationat the time of the transaction; (ii) if so, then generating, via the oneor more processors, an electronic notification notifying the card ownerof the real world merchant's name or identification, location of themerchant associated with the financial transaction, and/or that customerdata indicates that the customer was at the location of the merchant onthe day (and time) that the financial transaction occurred; and/or (iii)transmitting, via the one or more processors and/or transceivers, theelectronic notification to a customer mobile device for customer reviewand/or verification to facilitate resolving erroneous disputes caused byunrecognized financial transactions.

In another embodiment, a computer system configured to pre-empt fraud ortransaction disputes may be provided. The computer system may includeone or more processors and/or transceivers configured to: (1) receive,via wireless communication or data transmission over one or more radiolinks or wireless communication channels, an indication that a creditcard financial transaction is unrecognizable by the card owner; (2)determine or retrieve a billing alias for a merchant associated with theunrecognizable credit card transaction, the billing alias being named orprinted on a hardcopy, or contained within a digital, credit cardstatement; (3) determine a brick and mortar name that the merchantassociated with the billing alias is doing business as; (4) generate anelectronic notification indicating the brick and mortar name of themerchant associated with the credit card financial transaction; and/or(5) transmit, via wireless communication or data transmission over oneor more radio links or wireless communication channels, the electronicnotification indicating the brick and mortar name of the merchant to amobile device of the customer for customer review or approval tofacilitate preventing financial disputes caused by unrecognized orunfamiliar billing aliases on credit card or other financial statements.For instance, a brick and mortar merchant chain named Ten Guys Pizza &Shakes may have an unfamiliar billing company name or billing alias ofABC Corp.

Determining, via the one or more processors, the brick and mortar namethat the merchant associated with the billing alias is doing business asmay be performed by inputting the billing alias into a machine learningprogram trained to determine a real world name for the merchant usingthe billing alias. Determining or retrieving, via the one or moreprocessors, a billing alias for a merchant associated with theunrecognizable credit card transaction may include applying an OCRtechnique onto a billing statement to retrieve or determine the billingalias, or retrieving or determining the billing alias using digitalprocessor analysis on a digital billing or financial statement.

The one or more processors and/or transceivers may be further configuredto, prior to transmission of the electronic notification, determine ifthe real world merchant has a (GPS) location in a vicinity of thecustomer home address; and if so, receive customer mobile device orvehicle GPS coordinate history. The one or more processors and/ortransceivers may be configured to: (i) determine whether the card ownerwas at the (GPS) location of the real world merchant on the day (and/ortime) of the transaction based upon the customer mobile device orvehicle GPS coordinate history; (ii) if so, then generating, via the oneor more processors, an electronic notification notifying the card ownerof the real world merchant's name or identification, location of themerchant associated with the financial transaction, and/or that customerdata indicates that the customer was at the location of the merchant onthe day (and/or time) that the financial transaction occurred; and/or(iii) transmitting, via the one or more processors and/or transceivers,the electronic notification to customer mobile device for their reviewand/or verification to facilitate resolving erroneous disputes caused byunrecognized financial transactions.

The one or more processors and/or transceivers may be further configuredto: (i) compare a GPS location of the real world merchant associatedwith the transaction with customer location at the time of thetransaction to verify that the customer was at the merchant location atthe time of the transaction; (ii) if so, then generating, via the one ormore processors, an electronic notification notifying the card owner ofthe real world merchant's name or identification, location of themerchant associated with the financial transaction, and/or that customerdata indicates that they were at the location of the merchant on the daythat financial transaction occurred; and/or (iii) transmitting, via theone or more processors and/or transceivers, the electronic notificationto customer mobile device for their review and/or verification tofacilitate resolving erroneous disputes caused by unrecognized financialtransactions.

FIG. 7 illustrates a computer-implemented method 340 of reducingfinancial transaction disputes associated with introductory offersexpiring. The method 340 may include, via one or more processors and/ortransceivers (such as via wireless communication or data transmissionover one or more radio frequency links and/or wireless communicationchannels), (1) identifying an introductory offer offered by a companythat is associated with one or more customer disputes or complaintsafter the introductory offer has expired and after which an increasedamount is periodically charged to the customer (block 342); (2)receiving financial transaction activity associated with customers(block 344); and/or (3) identifying customers having financialtransaction activity associated with the introductory offer that isgenerating customer disputes or complaints (block 346). For instance, anoffending introductory offer and customer financial activity may beinput into a machine learning program that is trained to identifycustomers currently using the offending introductory offer. The method340 may include (4) generating and transmitting an electronicnotification indicating that the customer is currently using anintroductory offer that is associated with, or that has generated,customer complaints to the customer's mobile device for customer review(block 348).

The method 340 may include, (5) prior to notification transmission,determining when the introductory offer will expire for each customerand/or estimating a new or non-introductory cost of the underlyingproduct or service (block 350). For instance, the machine learningprogram may also be trained to identify expiration dates of theintroductory offer; estimate a regular cost of the underlying product orservice offered by the merchant from data indicating or describing theoffending introductory offer; and/or an average cost of the product orservice that is offered from multiple merchants. The method 340 mayinclude (6) generating an electronic notification detailing theintroductory offer, explaining when the introductory offer will expire,and/or what the customer will be, or will likely be, charged at thattime if they don't cancel the product or service associated with theintroductory offer beforehand (block 352); and/or (7) transmitting theelectronic notification (block 354) to facilitate the customercancelling the service before inflated charges are incurred, andreducing future financial disputes or customer dissatisfaction.

In one embodiment, a computer-implemented method of reducing financialtransaction disputes caused by introductory offers expiring may beprovided. The method may include (1) identifying, via one or moreprocessors, an introductory offer offered by a company that isassociated with, or generating, one or more customer disputes orcomplaints after the introductory offer has expired and an increasedamount (e.g., regular price) is periodically charged to the customer;(2) retrieving or receiving, via the one or more processors and/ortransceivers, financial transaction activity associated with customers;(3) identifying, via the one or more processors, customers havingfinancial transaction activity associated with the introductory offergenerating the one or more customer disputes or complaints; (4)generating, via the one or more processors, an electronic notificationindicating that the customers have accepted or are using an introductoryoffer that is generating customer complaints; and/or (5) transmitting,via the one or more processors and/or transceivers, the electronicnotification to customer mobile devices to facilitate customer reviewand cancellation of the introductory offer prior to expiration.

The method may further include, prior to electronic notificationtransmission, (i) determining, via the one or more processors, when theintroductory offer will expire for each customer; (ii) generating, viathe one or more processors, an electronic notification detailing theintroductory offer, and explaining when the introductory offer willexpire; and/or (iii) transmitting, via the one or more processors and/ortransceivers, the electronic notification to facilitate the customercancelling the service before inflated charges are incurred, andreducing future financial disputes.

The method may further include, prior to electronic notificationtransmission, (i) determining, via the one or more processors, what thecustomer will be charged after introductory offer expiration for aproduct or service; (ii) generating, via the one or more processors, anelectronic notification detailing the introductory offer, and explainingwhat the customer will be charged at that time if they don't cancel theproduct or service associated with the introductory offer beforehand;and/or (iii) transmitting, via the one or more processors and/ortransceivers, the electronic notification to a customer mobile device tofacilitate the customer cancelling the service before introductory offerexpiration and increased charges are incurred, and reducing futurefinancial disputes.

Determining, via the one or more processors, what the customer will becharged after introductory offer expiration may include an actualperiodic price charged by a merchant that produced the introductoryoffer; an average or estimated periodic price charged by a merchant thatproduced the introductory offer; and/or an average periodic pricecharged by merchants offering similar products or services than those ofthe introductory offer.

The method may include receiving, via the one or more processors and/ortransceivers, an authorization from a customer to cancel theintroductory for them from a customer mobile device; and/ortransmitting, via the one or more processors and/or transceivers, acancellation request to a merchant from which the introductory offeroriginates to cancel the introductory offer.

In another embodiment, a computer system configured to reduce financialtransaction disputes caused by introductory offers expiring may beprovided. The computer system may include one or more processors and/ortransceivers configured to: (1) identify an introductory offer offeredby a company that is associated with one or more customer disputes orcomplaints after the introductory offer has expired and an increasedamount is periodically charged to the customer; (2) retrieve or receivefinancial transaction activity associated with customers via wirelesscommunication or data transmission over one or more radio links orwireless communication channels from customer mobile devices or merchantcomputing devices; (3) identify customers having financial transactionactivity associated with the introductory offer generating the one ormore customer disputes or complaints; (4) generate an electronicnotification indicating that the customers have accepted, or are using,an introductory offer that is generating customer complaints; and/or (5)transmit the electronic notification to customer mobile devices viawireless communication or data transmission over one or more radio linksor wireless communication channels to facilitate customer review andcancellation of the introductory offer.

The one or more processors and/or transceivers may be further configuredto, prior to electronic notification transmission, (i) determine whenthe introductory offer will expire for each customer; (ii) generate anelectronic notification detailing the introductory offer, and explainingwhen the introductory offer will expire; and/or (iii) transmit theelectronic notification to a customer mobile device via wirelesscommunication or data transmission over one or more radio links orwireless communication channels to facilitate the customer cancellingthe service before introductory offer expiration and increased chargesare incurred, and reducing future financial disputes.

The one or more processors and/or transceivers may be further configuredto, prior to electronic notification transmission, (i) determine whatthe customer will be charged after introductory offer expiration; (ii)generate an electronic notification detailing the introductory offer,and explaining what the customer will be charged at that time if theydon't cancel the product or service associated with the introductoryoffer beforehand; and/or (iii) transmit the electronic notification to acustomer mobile device via wireless communication or data transmissionover one or more radio links or wireless communication channels tofacilitate the customer cancelling the product or service beforeintroductory offer expiration and increased charges are incurred, andreducing future financial disputes.

Determining, via the one or more processors, what the customer will becharged after introductory offer expiration may include an actualperiodic price charged by a merchant that produced the introductoryoffer, or an average or estimated price. Additionally or alternatively,determining, via the one or more processors, what the customer will becharged after introductory offer expiration may include an average orestimated periodic price charged by merchants offering similar productsor services than those of the introductory offer.

The one or more processors and/or transceivers may be further configuredto: (i) receive an authorization from a customer to cancel theintroductory for them from a customer mobile device via wirelesscommunication or data transmission over one or more radio links orwireless communication channels; and/or (ii) transmit, via wirelesscommunication or data transmission over one or more radio links orwireless communication channels, a cancellation request to a computingdevice or terminal associated with a merchant from which theintroductory offer originates to cancel the introductory offer.

VI. Exemplary System for Fraud Detection & Classification

FIG. 8 depicts an exemplary computer system 500 in which the techniquesdescribed herein may be implemented, according to one embodiment. Thecomputer system 500 of FIG. 8 may include a computing device in the formof a computer 510. Components of the computer 510 may include, but arenot limited to, a processing unit 520, a system memory 530, and a systembus 521 that couples various system components including the systemmemory 530 to the processing unit 520. The system bus 521 may be any ofseveral types of bus structures including a memory bus or memorycontroller, a peripheral bus, or a local bus, and may use any suitablebus architecture. By way of example, and not limitation, sucharchitectures include the Industry Standard Architecture (ISA) bus,Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, VideoElectronics Standards Association (VESA) local bus, and PeripheralComponent Interconnect (PCI) bus (also known as Mezzanine bus).

Computer 510 may include a variety of computer-readable media.Computer-readable media may be any available media that can be accessedby computer 510 and may include both volatile and nonvolatile media, andboth removable and non-removable media. By way of example, and notlimitation, computer-readable media may comprise computer storage mediaand communication media. Computer storage media may include volatile andnonvolatile, removable and non-removable media implemented in any methodor technology for storage of information such as computer-readableinstructions, data structures, program modules or other data. Computerstorage media may include, but is not limited to, RAM, ROM, EEPROM,FLASH memory or other memory technology, CD-ROM, digital versatile disks(DVD) or other optical disk storage, magnetic cassettes, magnetic tape,magnetic disk storage or other magnetic storage devices, or any othermedium which can be used to store the desired information and which canaccessed by computer 510.

Communication media typically embodies computer-readable instructions,data structures, program modules or other data in a modulated datasignal such as a carrier wave or other transport mechanism, and mayinclude any information delivery media. The term “modulated data signal”means a signal that has one or more of its characteristics set orchanged in such a manner as to encode information in the signal. By wayof example, and not limitation, communication media may include wiredmedia such as a wired network or direct-wired connection, and wirelessmedia such as acoustic, radio frequency (RF), infrared and otherwireless media. Combinations of any of the above are also includedwithin the scope of computer-readable media.

The system memory 530 may include computer storage media in the form ofvolatile and/or nonvolatile memory such as read only memory (ROM) 531and random access memory (RAM) 532. A basic input/output system 533(BIOS), containing the basic routines that help to transfer informationbetween elements within computer 510, such as during start-up, istypically stored in ROM 531. RAM 532 typically contains data and/orprogram modules that are immediately accessible to, and/or presentlybeing operated on, by processing unit 520. By way of example, and notlimitation, FIG. 8 illustrates operating system 534, applicationprograms 535, other program modules 536, and program data 537.

The computer 510 may also include other removable/non-removable,volatile/nonvolatile computer storage media. By way of example only,FIG. 8 illustrates a hard disk drive 541 that reads from or writes tonon-removable, nonvolatile magnetic media, a magnetic disk drive 551that reads from or writes to a removable, nonvolatile magnetic disk 552,and an optical disk drive 555 that reads from or writes to a removable,nonvolatile optical disk 556 such as a CD ROM or other optical media.Other removable/non-removable, volatile/nonvolatile computer storagemedia that can be used in the exemplary operating environment include,but are not limited to, magnetic tape cassettes, flash memory cards,digital versatile disks, digital video tape, solid state RAM, solidstate ROM, and the like. The hard disk drive 541 may be connected to thesystem bus 521 through a non-removable memory interface such asinterface 540, and magnetic disk drive 551 and optical disk drive 555may be connected to the system bus 521 by a removable memory interface,such as interface 550.

The drives and their associated computer storage media discussed aboveand illustrated in FIG. 8 provide storage of computer-readableinstructions, data structures, program modules and other data for thecomputer 510. In FIG. 8, for example, hard disk drive 541 is illustratedas storing operating system 544, application programs 545, other programmodules 546, and program data 547. Note that these components can eitherbe the same as or different from operating system 534, applicationprograms 535, other program modules 536, and program data 537. Operatingsystem 544, application programs 545, other program modules 546, andprogram data 547 are given different numbers here to illustrate that, ata minimum, they are different copies. A user may enter commands andinformation into the computer 510 through input devices such as cursorcontrol device 561 (e.g., a mouse, trackball, touch pad, etc.) andkeyboard 562. A monitor 591 or other type of display device is alsoconnected to the system bus 521 via an interface, such as a videointerface 590. In addition to the monitor, computers may also includeother peripheral output devices such as printer 596, which may beconnected through an output peripheral interface 595.

The computer 510 may operate in a networked environment using logicalconnections to one or more remote computers, such as a remote computer580. The remote computer 580 may be a personal computer, a server, arouter, a network PC, a peer device or other common network node, andmay include many or all of the elements described above relative to thecomputer 510, although only a memory storage device 581 has beenillustrated in FIG. 8. The logical connections depicted in FIG. 8include a local area network (LAN) 571 and a wide area network (WAN)573, but may also include other networks. Such networking environmentsare commonplace in hospitals, offices, enterprise-wide computernetworks, intranets and the Internet.

When used in a LAN networking environment, the computer 510 is connectedto the LAN 571 through a network interface or adapter 570. When used ina WAN networking environment, the computer 510 may include a modem 572or other means for establishing communications over the WAN 573, such asthe Internet. The modem 572, which may be internal or external, may beconnected to the system bus 521 via the input interface 560, or otherappropriate mechanism. The communications connections 570, 572, whichallow the device to communicate with other devices, are an example ofcommunication media, as discussed above. In a networked environment,program modules depicted relative to the computer 510, or portionsthereof, may be stored in the remote memory storage device 581. By wayof example, and not limitation, FIG. 8 illustrates remote applicationprograms 585 as residing on memory device 581.

The techniques for detecting and/or classifying fraud described abovemay be implemented in part or in their entirety within a computer systemsuch as the computer system 500 illustrated in FIG. 8. The computer 510may be included in AFSS 12 of FIG. 1, for example, and/or the remoteapplication programs 585 may include one or more applications of eitherFAMS 14, one of cardholder computing device 20, one of merchantcomputing systems 22, or a computing device of other sources 24.Moreover, the functionality of fraud detection/classification unit 36 ofFIG. 1 may be implemented by one or more of application programs 535and/or other program modules 536. As another example, ML rules database58, account holder behaviors database 60 and/or chargeback rulesdatabase 62 of FIG. 1 may be stored in hard disk drive 541 (e.g., asprogram data 547), magnetic disk 552 and/or optical disk drive 555,and/or the data retrieved by fraud detection/classification unit 36 ofFIG. 1 may be stored in hard disk drive 541 (e.g., as program data 547)and/or RAM 532 (e.g., as program data 537).

VII. Exemplary Method Embodiments

In one aspect, a computer-implemented method, implemented in one or moreservers or other computing devices, of facilitating a fraud disputeresolution process involving a customer associated with a financialaccount may include (1) identifying, by one or more processors of theone or more servers, types of information historically indicative offraud or an absence of fraud, at least in part by training a machinelearning program using at least (i) transaction data associated with aplurality of financial transactions, and (ii) fraud determinations eachcorresponding to a respective one of the plurality of financialtransactions; (2) receiving, by the one or more processors, anindication that fraud is suspected for a first financial transactionassociated with the financial account; (3) retrieving, by the one ormore processors and from an account records database, transaction dataassociated with the financial account; (4) generating, by the one ormore processors and based upon (i) at least one of the identified typesof information and (ii) the transaction data, a first set of one or morequeries designed to ascertain whether the first financial transactionwas fraudulent; (5) transmitting the first set of queries to a remotecomputing device to cause the first set of queries to be displayed tothe customer; (6) receiving, from the remote computing device, a firstset of one or more customer responses; and/or (7) determining, by theone or more processors and based upon the first set of customerresponses, whether the first financial transaction was fraudulent. Themethod may include additional, fewer or alternative actions, such as anyof those discussed elsewhere herein.

For instance, determining whether the first financial transaction wasfraudulent may include determining, by the one or more processors andbased upon the first set of customer responses, a second set of one ormore queries designed to ascertain whether the first financialtransaction was fraudulent. Additionally or alternatively, determiningwhether the first financial transaction was fraudulent may furtherinclude (1) transmitting the second set of queries to the remotecomputing device to cause the second set of queries to be displayed tothe customer; (2) receiving, from the remote computing device, a secondset of one or more customer responses; and/or (3) determining, by theone or more processors and based upon the second set of customerresponses, whether the first financial transaction was fraudulent.

Additionally or alternatively, generating the first set of one or morequeries may include generating at least one query designed to ascertainwhether (i) the customer was likely proximate to a location where thefirst financial transaction occurred at the time the first financialtransaction occurred; (ii) the customer recalls a second financialtransaction associated with the financial account; and/or (iii) thecustomer is aware of a billing alias associated with the first financialtransaction.

Additionally or alternatively, the method may further includes causing,by the one or more processors, an indication of whether the firstfinancial transaction was fraudulent to be displayed to one or morepeople via one or more respective computing device user interfaces.

VIII. Exemplary System Embodiments

In one aspect, a computer system for facilitating a fraud disputeresolution process involving a customer associated with a financialaccount may include (1) an account records database storing dataassociated with a plurality of financial accounts; (2) one or moreprocessors; and/or (3) a non-transitory memory. The memory storesinstructions that, when executed by the one or more processors, maycause the one or more processors to (1) identify types of informationhistorically indicative of fraud or an absence of fraud, at least inpart by training a machine learning program using at least (i)transaction data associated with a plurality of financial transactions,and (ii) fraud determinations each corresponding to a respective one ofthe plurality of financial transactions; (2) receive an indication thatfraud is suspected for a first financial transaction associated with thefinancial account; (3) retrieve, from the account records database,transaction data associated with the financial account; (4) generate,based upon (i) at least one of the identified types of information and(ii) the transaction data, a first set of one or more queries designedto ascertain whether the first financial transaction was fraudulent; (5)transmit the first set of queries to a remote computing device to causethe first set of queries to be displayed to the customer; (6) receive,from the remote computing device, a first set of one or more customerresponses; and/or (7) determine, based upon the first set of customerresponses, whether the first financial transaction was fraudulent. Thesystem may include additional, fewer or alternative components, featuresand/or functionality, such as any of those discussed elsewhere herein.

For instance, the instructions may cause the one or more processors todetermine whether the first financial transaction was fraudulent atleast by determining, based upon the first set of customer responses, asecond set of one or more queries designed to ascertain whether thefirst financial transaction was fraudulent. Additionally oralternatively, the instructions may cause the one or more processors todetermine whether the first financial transaction was fraudulent furtherby (1) transmitting the second set of queries to the remote computingdevice to cause the second set of queries to be displayed to thecustomer; (2) receiving, from the remote computing device, a second setof one or more customer responses; and/or (3) determining, by the one ormore processors and based upon the second set of customer responses,whether the first financial transaction was fraudulent.

The first set of one or more queries may include at least one querydesigned to ascertain whether the customer was likely proximate to alocation where the first financial transaction occurred at the time thefirst financial transaction occurred. Additionally or alternatively, thefirst set of one or more queries may include at least one query designedto ascertain whether the customer recalls a second financial transactionassociated with the financial account. Additionally or alternatively,the first set of one or more queries may include at least one querydesigned to ascertain whether the customer is aware of a billing aliasassociated with the first financial transaction. Additionally oralternatively, the instructions may further cause the one or moreprocessors to cause an indication of whether the first financialtransaction was fraudulent to be displayed to one or more people via oneor more respective computing device user interfaces.

IX. Exemplary Computer-Readable Medium Embodiments

In one aspect, a non-transitory, computer-readable medium storesinstructions that, when executed by one or more processors, may causethe one or more processors to: (1) identify types of informationhistorically indicative of fraud or an absence of fraud, at least inpart by training a machine learning program using at least (i)transaction data associated with a plurality of financial transactions,and (ii) fraud determinations each corresponding to a respective one ofthe plurality of financial transactions; (2) receive an indication thatfraud is suspected for a first financial transaction associated with thefinancial account; (3) retrieve, from an account records database,transaction data associated with the financial account; (4) generate,based upon (i) at least one of the identified types of information and(ii) the transaction data, a first set of one or more queries designedto ascertain whether the first financial transaction was fraudulent; (5)transmit the first set of queries to a remote computing device to causethe first set of queries to be displayed to the customer; (6) receive,from the remote computing device, a first set of one or more customerresponses; and/or (7) determine, based upon the first set of customerresponses, whether the first financial transaction was fraudulent. Thecomputer-readable medium may store instructions that include additional,fewer or alternative actions, such as any of those discussed elsewhereherein.

For instance, the instructions may cause the one or more processors todetermine whether the first financial transaction was fraudulent atleast by (1) determining, based upon the first set of customerresponses, a second set of one or more queries designed to ascertainwhether the first financial transaction was fraudulent; (2) transmittingthe second set of queries to the remote computing device to cause thesecond set of queries to be displayed to the customer; (3) receiving,from the remote computing device, a second set of one or more customerresponses; and/or (4) determining, by the one or more processors andbased upon the second set of customer responses, whether the firstfinancial transaction was fraudulent.

Additionally or alternatively, the first set of one or more queries mayinclude at least one query designed to ascertain whether the customerwas likely proximate to a location where the first financial transactionoccurred at the time the first financial transaction occurred.Additionally or alternatively, the first set of one or more queries mayinclude at least one query designed to ascertain whether the customerrecalls a second financial transaction associated with the financialaccount. Additionally or alternatively, the first set of one or morequeries may include at least one query designed to ascertain whether thecustomer is aware of a billing alias associated with the first financialtransaction. Additionally or alternatively, the instructions may furthercause the one or more processors to cause an indication of whether thefirst financial transaction was fraudulent to be displayed to one ormore people via one or more respective computing device user interfaces.

X. Additional Considerations

The following additional considerations apply to the foregoingdiscussion. Throughout this specification, plural instances mayimplement operations or structures described as a single instance.Although individual operations of one or more methods are illustratedand described as separate operations, one or more of the individualoperations may be performed concurrently, and nothing requires that theoperations be performed in the order illustrated. These and othervariations, modifications, additions, and improvements fall within thescope of the subject matter herein.

1. A computer-implemented method of pre-empting fraud disputes caused bybilling aliases or unrecognized merchant billing names, the methodcomprising: receiving historical data associated with a plurality ofaccount holders, the historical data comprising first information abouta plurality of historical financial transactions and second informationincluding historical vehicle telematics data; receiving frauddetermination labels associated with the historical data; inputting thehistorical data and the fraud determination labels into a machinelearning model; receiving, as an output from the machine learning model,a plurality of query generation rules; receiving, by one or moreprocessors, an indication that a credit card financial transaction isunrecognizable by a card owner; applying, based at least in part on theindication, one or more of the query generation rules, by the one ormore processors, to: determine a billing alias for a merchant associatedwith the credit card financial transaction, the billing alias beingnamed on a credit card statement as a billing merchant, determine abrick and mortar name that the merchant associated with the billingalias is doing business as, determine a Global Positioning System (GPS)location of the merchant, receive a GPS coordinate history of a mobiledevice or a vehicle of the card owner, owner; determine that the cardowner was within a threshold distance of the GPS location of themerchant on a day of the credit card financial transaction based on theGPS coordinate history, the threshold distance being determined from theone or more of the query generation rules, and based on determining thatthe card owner was within the threshold distance, generate an electronicnotification notifying the card owner of one or more of (i) the brickand mortar name of the merchant, (ii) the GPS location of the merchant,or (iii) that the card owner was at the GPS location of the merchant onthe day of the credit card financial transaction; transmitting, by theone or more processors, the electronic notification to the mobile deviceof the card owner for card owner review or verification to facilitateresolving erroneous disputes caused by unrecognized financialtransactions; and training the machine learning model based at least inpart on a response of the card owner to the electronic notification. 2.The computer-implemented method of claim 1, wherein determining thebrick and mortar name is performed by inputting the billing alias into amachine learning program trained to determine a real world name for themerchant associated with the billing alias.
 3. The computer-implementedmethod of claim 1, wherein the determining the billing alias for themerchant includes applying an Optical Character Recognition (OCR)technique to a digital or hardcopy billing statement to determine thebilling alias. 4.-6. (canceled)
 7. The computer-implemented method ofclaim 1, wherein receiving the indication that the credit card financialtransaction is unrecognizable occurs over one or more radio frequencylinks.
 8. A computer system configured to pre-empt fraud disputes, thecomputer system comprising one or more processors configured to: receivehistorical data associated with a plurality of account holders, thehistorical data comprising first information about a plurality ofhistorical financial transactions and second information includinghistorical vehicle telematics data; receive fraud determination labelsassociated with the historical data; input the historical data and thefraud determination labels into a machine learning model; receive, as anoutput from the machine learning model, a plurality of query generationrules; receive an indication that a credit card financial transaction isunrecognizable by a card owner; apply, based at least in part on theindication, one or more of the query generation rules, by the one ormore processors, to: determine a billing alias for a merchant associatedwith the credit card financial transaction, the billing alias beingnamed on a credit card statement as a billing merchant, determine abrick and mortar name that the merchant associated with the billingalias is doing business as, determine a GPS location of the merchant,receive a GPS coordinate history of a mobile device or a vehicle of thecard owner; determine that the card owner was within a thresholddistance of the GPS location of the merchant on a day of the credit cardfinancial transaction based on the GPS coordinate history, the thresholddistance being determined from the one or more of the query generationrules, and based on determining that the card owner was within thethreshold distance, generate an electronic notification notifying thecard owner of one or more of (i) the brick and mortar name of themerchant, (ii) the GPS location of the merchant, or (iii) that the cardowner was at the GPS location of the merchant on the day of the creditcard financial transaction; transmit the electronic notification to themobile device of the card owner for card owner review or verification tofacilitate resolving erroneous disputes caused by unrecognized financialtransactions; and train the machine learning model based at least inpart on a response of the card owner to the electronic notification. 9.The computer system of claim 8, wherein the determining the brick andmortar name that the merchant associated with the billing alias is doingbusiness as is performed by inputting the billing alias into a machinelearning program trained to determine a real world name for the merchantassociated with the billing alias.
 10. The computer system of claim 8,wherein determining the billing alias for the merchant includes applyingan Optical Character Recognition (OCR) technique to a digital orhardcopy billing statement.
 11. The computer system of claim 8, whereinthe determining the billing alias for the merchant includes retrievingthe billing alias using digital processor analysis on a digital billingor financial statement. 12.-14. (canceled)
 15. A non-transitory,computer-readable medium storing instructions that, when executed by oneor more processors, cause the one or more processors to: receivehistorical data associated with a plurality of account holders, thehistorical data comprising first information about a plurality ofhistorical financial transactions and second information includinghistorical vehicle telematics data; receive fraud determination labelsassociated with the historical data; input the historical data and thefraud determination labels into a machine learning model; receive, as anoutput from the machine learning model, a plurality of query generationrules; receive an indication that a credit card financial transaction isunrecognizable by a card owner; apply, based at least in part on theindication, one or more of the query generation rules, by the one ormore processors, to: determine a billing alias for a merchant associatedwith the credit card financial transaction, the billing alias beingnamed on a credit card statement as a billing merchant, determine abrick and mortar name that the merchant associated with the billingalias is doing business as, determine that the merchant has a GPSlocation in a vicinity of a home address of the card owner; determine aGPS location of the merchant, receive a GPS coordinate history of amobile device or a vehicle of the card owner; determine that the cardowner was within a threshold distance of the GPS location of themerchant on a day of the credit card financial transaction based on theGPS coordinate history, the threshold distance being determined from theone or more of the query generation rules, and based on determining thatthe card owner was within the threshold distance, generate an electronicnotification notifying the card owner of one or more of (i) the brickand mortar name of the merchant, (ii) the GPS location of the merchant,or (iii) that the card owner was at the GPS location of the merchant onthe day of the credit card financial transaction; transmit theelectronic notification to the mobile device of the card owner for cardowner review or verification to facilitate resolving erroneous disputescaused by unrecognized financial transactions; and train the machinelearning model based at least in part on a response of the card owner tothe electronic notification.
 16. The non-transitory, computer-readablemedium of claim 15, wherein the one or more processors are configured todetermine the brick and mortar name that the merchant associated withthe billing alias is doing business as at least by inputting the billingalias into a machine learning program trained to determine a real worldname for the merchant associated with the billing alias.
 17. Thenon-transitory, computer-readable medium of claim 15, wherein the one ormore processors are configured to determine the billing alias for themerchant at least in part by applying an OCR technique to a digital orhardcopy billing statement.
 18. The non-transitory, computer-readablemedium of claim 15, wherein the one or more processors are configured todetermine the billing alias for the merchant at least in part byretrieving the billing alias using digital processor analysis on adigital billing or financial statement. 19.-20. (canceled)
 21. Thecomputer-implemented method of claim 1, further comprising: receiving,by the one or more processors from the mobile device of the card holder,a response indicating that the credit card financial transaction isunverified by the card holder; and based on the response, determining,by the one or more processors, that the credit card financialtransaction is fraudulent.
 22. The computer-implemented method of claim1, further comprising: receiving, by the one or more processors from themobile device of the card holder, a response indicating that the creditcard financial transaction is verified by the card holder; and based onthe response, determining, by the one or more processors, that thecredit card financial transaction is approved.
 23. Thecomputer-implemented method of claim 1, wherein the electronicnotification indicates (i) the brick and mortar name of the merchant,(ii) the GPS location of the merchant, and (iii) that the card owner wasat the GPS location of the merchant on the day of the credit cardfinancial transaction.
 24. The computer system of claim 8, wherein theone or more processors are further configured to: receive, from themobile device of the card holder, a response indicating that the creditcard financial transaction is unverified by the card holder; and basedon the response, determine that the credit card financial transaction isfraudulent.
 25. The computer system of claim 8, wherein the one or moreprocessors are further configured to: receive, from the mobile device ofthe card holder, a response indicating that the credit card financialtransaction is verified by the card holder; and based on the response,determine that the credit card financial transaction is approved. 26.The computer system of claim 8, wherein the electronic notificationindicates (i) the brick and mortar name of the merchant, (ii) the GPSlocation of the merchant, and (iii) that the card owner was at the GPSlocation of the merchant on the day of the credit card financialtransaction.
 27. The non-transitory, computer-readable medium of claim15, wherein the instructions, when executed by one or more processors,further cause the one or more processors to: receive, from the mobiledevice of the card holder, a response indicating that the credit cardfinancial transaction is verified by the card holder; and based on theresponse, determine that the credit card financial transaction isapproved.
 28. The non-transitory, computer-readable medium of claim 15,wherein the electronic notification indicates (i) the brick and mortarname of the merchant, (ii) the GPS location of the merchant, and (iii)that the card owner was at the GPS location of the merchant on the dayof the credit card financial transaction.